OpenBSD Releases Meltdown Patch (theregister.co.uk) 44
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.
AMD (Score:3)
Re: (Score:3)
this patch was for meltdown only which doesn't affect AMD; note the situation for the various types of SPECTRE are a mess, even the chip makers are floundering around. Intel put out yet another new spectre variant firmware fix *yesterday*!
Re: (Score:2)
Are we so sure it does not affect AMD? (Score:2, Interesting)
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 Meltd
Re: (Score:3)
Only AMD escaped? Only Intel is affected by Meltdown.
Re: (Score:3)
Anybody with any clue would realize that your ass is doing the talking. Spectre* is much harder to exploit than Meltdown, Meltdown essentially allow any user process to read any memory in a unpatched OS without needing to know anything specific about the system while the other attacks (Spectre) require knowledge of a certain system specific vulnerability and can then read some limited information. Big difference.
(* which technically includes Meltdown - which AMD isn't affected by)
Re: (Score:2, Informative)
There were two recent vulnerability announcements.
Meltdown (which affects only Intel)
Spectre (which affects Intel, AMD, ARM, and probably more)
Intel has done a *great* job of making it sound like they're one and the same, and everyone's affected.
Meltdown is fixable.
Spectre isn't fully fixable yet, afaik.
On a related note, think about what Spectre really means for your public cloud workloads...
Re: (Score:1)
Hmm, could have sworn Meltdown also affected ARM. I knew Spectre was wider spread but I thought Meltdown also crossed a few processors... guess I was misremembering that aspect.
Re: (Score:1)
It's mostly Intel-specific, because Intel patented the go-marginally-faster-by-hardwiring-hardware-to-heuristically-skip-bounds-check technique that basically is the Meltdown vulnerability. IBM licensed it for some of their POWER chips. The one and only ARM core to use it is the Cortex-A75. So ARM is perfectly safe if you avoid Cortex-A75, which is easy enough.
In practice, if it's Intel then it's probably affected, otherwise you're most likely safe.
Re: (Score:3)
Intel propaganda have tried to make people think Spectre == Meltdown and so all processor manufacturers are equally affected.
That is of course not true. But Intel have succeeded in planting that even into technical people.
Re:Are we so sure it does not affect AMD? (Score:5, Informative)
"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
That's technical enough. No matter how the timing is tweaked AMD isn't vulnerable.
Re: (Score:2)
Re: (Score:1)
Thanks. That's exactly the level of information I was looking for.
Re: (Score:3)
AMD is affected by things similar to Spectre, slightly less than Intel but still an issue. It doesn't have the specific Meltdown vulnerability.
The real question is what does all this context switching cost in terms of speed and system resources.
Re: (Score:1)
Specifically, out of the 3, AMD is only affected by the bounds check vulnerability, not the branch target predictor nor (the worst) Meltdown.
what does all this context switching cost in terms of speed and system resources
To answer your question, the wiki article on KPTI [wikipedia.org] says:
(note that the PCID optimization refers to the use of this [wikipedia.org] to prevent TLB flushing every time the contexts are switched)
The overhead was measured to be 0.28% according to KAISER's original authors; a Linux developer measured it to be roughly 5% for most workloads and up to 30% in some cases, even with the PCID optimization; for database engine PostgreSQL the impact on read-only tests on an Intel Skylake processor was 7–17% (or 16–23% without PCID), while a full benchmark lost 13–19% (Coffee Lake vs. Broadwell-E). Many benchmarks have been done by Phoronix, Redis slowed by 6–7%. Linux kernel compilation slowed down by 5% on Haswell.
Re: (Score:2)
Hugs all around! (Score:4, Funny)
Great work everyone!
Re: Hugs all around! (Score:2, Insightful)
You didnâ(TM)t get the consent required. Please report to HR or the FreeBSD board of stupidity.
Re: (Score:2)
That's harassment!
Well, yeah (Score:2)
Re: (Score:2)
Re: (Score:1)
If they use a single page table and have kernel memory mapped while running user mode then yes.
Re: (Score:2)
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 [fosdem.org] (minute 31:19 of the video)
Philipp
Re: (Score:2)
It affects every situation where memory is flagged as unreadable.
Processors afected by Meltdown: (Score:3, Informative)
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... [amd.com]
[4] https://www.ibm.com/blogs/psir... [ibm.com]
[5] https://developer.arm.com/supp... [arm.com]
The Full Blog is here:
https://technologyunderbelly.b... [blogspot.com]
"same approach as Linux" (Score:2)
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.
Re: "same approach as Linux" (Score:1)
Are you one of those security by obscurity fucktards who thinks having only a few special mega corps and every serious black hat know while the rest of us get ass raped every day by those same black hats us9ng an unknown to us 6 month old 0-day is good practice?
Fucking moron.
If they don't fix this meldown crap soon ... (Score:2)
...I'll have a meltdown.