Date: Sat, 6 Jan 2018 20:00:20 +0100 From: Gary Jennejohn <gljennjohn@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Wojciech Puchar <wojtek@puchar.net>, 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: <20180106200020.051c4149@ernst.home> In-Reply-To: <CANCZdfqsV1bUAmwVGHZZfBK2FQ_Y03WvHQuUtBOABHo6mbbYAA@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 6 Jan 2018 10:04:54 -0700 Warner Losh <imp@bsdimp.com> wrote: > On Sat, Jan 6, 2018 at 9:53 AM, Wojciech Puchar <wojtek@puchar.net> wrote: > > > While is doesn't defeat the attack, tt does still complicate > >> attacks, so > >> I think it's worth considering. > >> > >> > >> The problem is that the attempts to access kernel space are speculative. > >> There's no way to get the 'speculative trap' that would > >> have been generated had the code actually executed. There literally is no > >> signal to the kernel this just happened. > >> > >> Warner > >> > >> > >> f..k. so there are no real workarounds. Anyway - if CPU companies would > > be honest they would replace at least all server CPUs that are on warranty > > > The only workaround that's completely effective is to unmap all of kernel > memory when running in userland. It's a bit tricky because 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). > This point is addressed in one of the papers. KAISER only maps small parts of the address space, which are apparently required for special use, in both the kernel and user space. Otherwise, the kernel and user space do not share any part of the memory map. The conclusion in the paper is that, yes, a small part of memory is still common to both the kernel and user space, but if KASLR is used, then it will be very difficult to identify these ranges. -- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180106200020.051c4149>