On Sun, Jan 21, 2018 at 02:00:45PM +0100, Maxime Villard wrote: > I committed this morning the last part needed to completely mitigate Meltdown > on NetBSD-amd64. As I said in the commit message, we still need to change a > few things for KASLR - there is some address leakage, we need to hide one > instruction -, but otherwise the implementation should be perfectly > functional. > > You can enable it by uncommenting > > #options SVS # Separate Virtual Space > > and building a GENERIC or GENERIC_KASLR kernel. Currently there is no dynamic > detection - that is to say, if you enable SVS, it remains enabled on AMD CPUs. > As I said a few weeks ago I have a patch for that, but it's not in the tree > yet. > > My plan, once the dynamic detection is in, is to enable 'options SVS' by > default. Then, when the kernel boots, if the CPU is not from Intel, SVS is > disabled automatically (by either hotpatching or replacing the interrupt entry > points). Once the system is up, the user will be able to disable SVS manually > with a sysctl of the kind: > > # sysctl -w machdep.svs.enabled=0 > > This way if you have an Intel CPU, and you want good performances or don't > care a lot about security, you will still be able to fall back to the default > mode. > > Unfortunately, the two Meltdown PoCs I tested on my i5 didn't work, and this, > even with SVS disabled. Basically, I'm not able to make sure Meltdown is > indeed mitigated entirely, but I'm able to make sure that userland runs with > most of the kernel pages unmapped. > > If someone with a functional PoC and vulnerable CPU could test SVS, that > would be nice. For example the PoC Taylor sent on tech-kern a few days ago; > it should be mitigated. > > Also, it would be nice if someone familiar with x86 could proof-read the code > I wrote, since it touches pretty critical places. Most of the code is at the > end of [2], and the middle of [3] (SVS_* and TEXT_USER_*).
I've tested it using following PoC: https://github.com/logicaltrust/meltdown on: cpu0: "Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz" I can successfully exploit this issue on an older kernel, but after applying your patches the bug is gone (GENERIC with SVS enabled). Thanks for your work! Mateusz
