A more general possible meltdown/spectre countermeasure

[Gary Jennejohn]

On Sat, 6 Jan 2018 10:04:54 -0700
Warner Losh <imp at bsdimp.com> wrote:

> On Sat, Jan 6, 2018 at 9:53 AM, Wojciech Puchar <wojtek at 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