Slashdot Mirror
OpenBSD Releases Meltdown Patch (theregister.co.uk)
OpenBSD's Meltdown patch has landed, in the form of a Version 11 code update that separates user memory pages from the kernel's -- pretty much the same approach as was taken in the Linux kernel. From a report: A few days after the Meltdown/Spectre bugs emerged in January, OpenBSD's Phillip Guenther responded to user concerns with a post saying the operating system's developers were working out what to do. Now he's revealed the approach used to fix the free OS: "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." That explanation is somewhat obscure to non-developers, but there's a more readable discussion of what the project's developers had in mind from January, here.
I am running AMD processors. Does this affect me, or only Intel processors?
Great work everyone!
she's dead jim
Fake news! to get you to buy more C.P.U.s rather than more hookers.
Well, sure ... that's what I was going to say.
I have nothing against AMD, and in general support competition for Intel...
But are we truly sure the Meltdown approach cannot work on AMD? From all of the reading I did doing the Meltdown fiasco, it seemed like the people who came up with Meltdown thought it might work on AMD, they could just not get the timing to work quite right in a proof of concept attack the way they could with Intel...
Is there a more detailed technical description laying out exactly why AMD processors are for sure immune to the Meltdown attack? It seemed that with something that affected so many different processors, it's strange that only AMD escaped.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Comment removed based on user account deletion
If they use a single page table and have kernel memory mapped while running user mode then yes.
I know it's copied verbatim from the article, but if you read the actual developer discussion the whole stack frame thing begins to make more sense.
Kernel mode code already uses it's own stack. This is normal. The new feature here is that they add an intermediate stack that is only used while switching the page tables, and in fact this whole stack discussion is merely an implementation detail. The actual fix here is isolating kernel and user page tables.
Many Linuxes have at least applied the Intel microcode patches and the kernel-level Spectre mitigations. What they have done is not adequate. It's not clear all the VM guest-guest switches are properly protected, and there are chip variant caveats, and some bits of userland need fixes which isn't done.
Specifically, any part of the userland that runs untrusted code, like web browsers that run Javascript, should be recompiled with retpoline, and most Linuxes don't ship the correct C compiler to do that. How is OpenBSD's web browser doing? Do they even provide a retpoline-capable compiler?
Does OpenBSD have qemu/kvm/Xen? If so, is it spectre-mitigated?
Even beyond speculative execution attacks, these bugs call attention to the danger of cache timing attacks which may become a more fruitful class of exploits soon. But that's not a place where OpenBSD is lagging. I think they may be lagging on spectre mitigation specifically (though Linux isn't doing great, either).
Remember this is all 8 months out. It is really kinda extreme that Google broke their standard timeline and took an 6-month head start on the industry to fix GCE. I suppose it is fair since it's their own research. If they are funding this massive highly-competent security team in house, the benefit that GCE is more secure than competitors is not unreasonable. It's a little annoying, politically, that they cooperated with their big competitors, but it's socially practical to cooperate with those who could keep secrets and who affected many users. Anyway they're not asking someone else to delay disclosure to be "responsible" which would be hypocritical. It's their own discovery. I don't think Google's going beyond what they're entitled to with how they handled this discovery, at all, so let me be clear on that since it's so fashionable for people to imagine their relation to Google as a sort of entitled serfdom, and that's bullshit. I'm just saying their odd behaviour reveals the present situation is exceptional, so OpenBSD, Linux communities, AMD and Intel (to the extent they can release ucode) are being tested in an exceptional manner right now.
But in the response to Spectre, the result of the test is disappointing flail.
In other words, if they are using an Intel processor with any kernel, the answer is yes they are affected and this includes qnx and minix and etc, unless they are in some old unprotected mode which disables all the cool features like these things that are being exploited like dos 5 or something. ;)
Meltdown and Spectre are huge issues for Microkernels. For details see the answer to a question to one of the Hurd developers after the end of the FOSDEM 2018 talk on Hurd's PCI arbiter (minute 31:19 of the video)
Philipp
From my blog:
Meltdown affects all Intel Processors with Out-of-Order-Execution (OOE) and, more importantly, Speculative-Execution, perhaps going back to the Original PentiumPro, and all Atom processors made after 2013 (the original Atoms were In-Order-Execution). AMD processors are immune [3], and Via (remember Via?) has remained silent. Meltdown also affects other architectures, like several ARM processors, including the up-and-coming Cortex-A75 (intended for datacenter use), as well as many others used in cellphones and appliances [5], also IBM’s POWER7+, 8 and 9 are affected [4]. But this paper is not concerned with other architectures.
[3] https://www.amd.com/en/corpora...
[4] https://www.ibm.com/blogs/psir...
[5] https://developer.arm.com/supp...
The Full Blog is here:
https://technologyunderbelly.b...
*** Suerte a todos y Feliz dia!
It affects every situation where memory is flagged as unreadable.
I don't think it's as bad as he is making out, since you could still use page table isolation even in a micro kernel.
It doesn't matter if the kernel can see everything. That is the case even in the proposed BSD patch.
What matters is that the user space processes cannot see the kernel.
So as long as they do their memory copying from one process to another in kernel mode, then they can give the kernel access to everything and the userspace only access to the parts of the kernel needed to handle an interrupt and switch into proper kernel mode.
Describing Guenther's patch as "pretty much the same approach as was taken in the Linux kernel" makes it sounds like he just copied someone else's idea. I think the reality is that kernel developers from numerous platforms have been brainstorming approaches to Meltdown and Spectre.
I realize this is Slashdot, but please don't try to turn Guenther's achievement into a "Woohoo LINUX!!!" story.
...I'll have a meltdown.