The meltdown and spectre vulnerabilities

Everyone is talking about the meltdown and the spectre vulnerabilities now. If you are late to the party, read https://meltdownattack.com/ 

Of course we are aware of it and took time to assess the risks for VyOS. Since both vulnerabilities can only be exploited locally, the risk for a typical VyOS installation is very low: if an untrusted person managed to login to your router, you are already deep in trouble and unathorized access to the OS memory is arguably the least of your concerns since even operator level users can make traffic dumps.

The fix will not be included in 1.1.9. Since the fix is associated with an up to 30% performance penalty, in 1.2.x, we will make it optional is feasible.

11 responses
While browsing kernel commits around this I've noticed that there are stubs for affected/unaffected CPUs, but it is not yet fully implemented. Right now the approach is "assume all CPUs are vulnerable". It might be better to wait for that new portion of the codebase to settle down a bit in any case.
Hi Chris, it looks like the kernel address space isolation can be disabled in the kernel command line at boot, so even before the kernel makes it automated, it may be possible to add a command like "set system options kernel-space-isolation enable".
Hi Daniel! It seems those 30% claims were wild speculation and are not confirmed, but it's definitely true that there should be a performance penalty on syscalls, so I expect network devices to feel the pain.
I'm not really worried about someone having access to my routers and being able to run code, however the potential danger comes from virtual environments in my opinion. When running VyOS in a cloud environment another vm could potentially read memory from a VyOS router. At least that's what people are talking about. So running VyOS on dedicated hardware or in a private cloud should be safe, running in a public cloud isn't sure, guess a lot of people do this.
Werner, in fully virtualized systems, as long as hypervisor as patched, the attack is only possible within the VM, while if it's not patched, patching the VM would do nothing. At least that's how I understand the paper and what other opinions I could find confirm. If someone proves otherwise, this will become a top priority of course.
Thanks for your answer Daniel... To me it's still a bit unclear as VMWare says their patches work together with the OS patches. I guess the next few days more info will be available. At the moment it seems everyone is trying to get a lot of hits on their newssites with articles that are probably not 100% correct or complete.
Yeah, I did take time to read the original papers at the point when all such articles were entirely speculative, but decided to refrain from writing elaborate articles because I hardly have time to learn the details of speculative execution implementation in Intel's CPUs to predict how it will behave in every possible case. ;)
Hi Daniel, I'll contact VMWare tomorrow to ask them for an explanation what their patch is doing exactly, if that alone is enough to prevent inter vm attacks. If I have more info I'll let you know. Best regards, Werner
3 visitors upvoted this post.