A more general possible meltdown/spectre countermeasure

[Rang, Anton]

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 at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"