[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Current state of SVS and Meltdown
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
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
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 , and the middle of  (SVS_* and TEXT_USER_*).
Please test, thanks,
Main Index |
Thread Index |