Contributed by Paul 'WEiRD' de Weerd on from the so-hot-of-the-press-it-melts-your-cpu dept.
Meltdown mitigation is coming to OpenBSD. Philip Guenther (guenther@) has just committed a diff that implements a new mitigation technique to OpenBSD: Separation of page tables for kernel and userland. This fixes the Meltdown problems that affect most CPUs from Intel. Both Philip and Mike Larkin (mlarkin@) spent a lot of time implementing this solution, talking to various people from other projects on best approaches.
In the commit message, Philip briefly describes the implementation:
Meltdown: implement user/kernel page table separation. On Intel CPUs which speculate past user/supervisor page permission checks, use a separate page table for userspace with only the minimum of kernel code and data required for the transitions to/from the kernel (still marked as supervisor-only, of course): - the IDT (RO) - three pages of kernel text in the .kutext section for interrupt, trap, and syscall trampoline code (RX) - one page of kernel data in the .kudata section for TLB flush IPIs (RW) - the lapic page (RW, uncachable) - per CPU: one page for the TSS+GDT (RO) and one page for trampoline stacks (RW) When a syscall, trap, or interrupt takes a CPU from userspace to kernel the trampoline code switches page tables, switches stacks to the thread's real kernel stack, then copies over the necessary bits from the trampoline stack. On return to userspace the opposite occurs: recreate the iretq frame on the trampoline stack, switch stack, switch page tables, and return to userspace. mlarkin@ implemented the pmap bits and did 90% of the debugging, diagnosing issues on MP in particular, and drove the final push to completion. Many rounds of testing by naddy@, sthen@, and others Thanks to Alex Wilson from Joyent for early discussions about trampolines and their data requirements. Per-CPU page layout mostly inspired by DragonFlyBSD.
Even with extensive testing by developers, editors@ are sure more testing would be welcome. So grab a snapshot (if they're from February 22nd or later, they should contain the diff) and see how this behaves in your environment!
(Comments are closed)
By ilyes aiouaz (ilyes_aiouaz) firstname.lastname@example.org on https://www.ulysse-lab.com
By grab mov (grabmov) email@example.com on http://sakubola.com
wow, cool bro congratulations,
By Renaud Allard (renaud) firstname.lastname@example.org on
Congratulations on the good job, that was fast.
By Noryungi (noryungi) email@example.com on
That is excellent news! Thanks to everyone involved!
By brynet (Brynet) on https://brynet.biz.tm/
Congrats! Many thanks to mlarkin@ & guenther@ for their tireless efforts to get this work in.
By Troy (rits) firstname.lastname@example.org on
By Peter J. Philipp (pjp) email@example.com on http://centroid.eu
Thank you! This is great. I installed the snapshot from Feb 22nd. So far there seems no panics, no inhibitions, and it's fast AND zzz worked too over night. My workstation is a Xeon E3-1275v3 where I tested this on. Thanks again!
By Amit Kulkarni (amitkulz) on
There's no snapshot for Feb 22 released yet! You probably installed from Feb 21.
By Daniel Gracia (Paladdin) on http://www.egracia.es
So far, so good; I'm loving it!
By Amit Kulkarni (amitkulz) on
Wow, superb work as always!
By Just another grumpy fart (grumpy_fart) firstname.lastname@example.org on http://www.openbsd.org/
Isn't it amazing how a couple of volunteers, in their spare time, manage to roll out a working solution to this dumpster truck fire for our favourite OS, where several vendors were fumbling around for months.
Responsible disclosure my ass. Highly irresponsible, if you ask me. No wonder people are taking Intel to court over this shit storm.