Date: Mon, 8 Jan 2018 17:28:20 +0000 From: "Rang, Anton" <Anton.Rang@dell.com> To: Wojciech Puchar <wojtek@puchar.net> Cc: Warner Losh <imp@bsdimp.com>, Eric McCorkle <eric@metricspace.net>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: A more general possible meltdown/spectre countermeasure Message-ID: <6AF5185E-201A-4C8E-B4ED-B30C65E36E99@isilon.com> In-Reply-To: <alpine.BSF.2.20.1801062140090.71856@puchar.net> References: <c98b7ac3-26f0-81ee-2769-432697f876e5@metricspace.net> <33bcd281-4018-7075-1775-4dfcd58e5a48@metricspace.net> <alpine.BSF.2.20.1801061701200.40627@puchar.net> <73d2f1a5-55f7-0ae7-7660-3e680ba3d32e@metricspace.net> <CANCZdfqZnZhKXD3SKgyro%2BYLX7j5BYrmCZ7xEGwYY6AWkQpKzg@mail.gmail.com> <alpine.BSF.2.20.1801061752540.46832@puchar.net> <CANCZdfqsV1bUAmwVGHZZfBK2FQ_Y03WvHQuUtBOABHo6mbbYAA@mail.gmail.com> <alpine.BSF.2.20.1801062140090.71856@puchar.net>
index | next in thread | previous in thread | raw e-mail
The tables aren’t changed on each transition; rather, two page tables are maintained, one which has an entry for the kernel mappings at the top level and one which does not. Then it’s simply a matter of changing which page table is examined (by writing to CR3) on transition. If PCID is available, previously-used mappings can stay cached in the TLB through this, though they won’t be shared between user/kernel (so in general syscalls will incur an additional translation per buffer page). Anton > On Jan 6, 2018, at 2:41 PM, Wojciech Puchar <wojtek@puchar.net> wrote: > >> The only workaround that's completely effective is to unmap all of kernel memory when running in userland. It's a bit tricky because > > this means on every syscall on interrupt: > > - memcopy part of top level PTE on enter, bzero on exit > - TLB flush both on enter and exit. > > IMHO it would make much more than 30% overhead in many cases. am i wrong? > >> there's small parts that have to stay mapped for various architectural reasons. This means KASLR on these CPUs likely can never be >> effective since meltdown will let you find what the trap address is and from that find the kernel (though there's some rumblings >> that the indirection Linux is doing will suffice). >> Warner >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6AF5185E-201A-4C8E-B4ED-B30C65E36E99>