Re: Meltdown, aka "Dear Intel, you suck"
> From: Philip Guenther > Date: Fri, 5 Jan 2018 20:52:20 -0800 > > Unless something unexpected happens, we'll be applying the workaround to > amd64 first and then working out what to do for i386 and arm* (if still > though to be necessary for arm) after that. FWIW, Meltdown is a non-issue for OpenBSD/armv7 and OpenBSD/arm64 at the moment. The only vulnerable ARM core is the Cortex-A75 which isn't actually on the market yet. And we don't currently support non-ARM implementations. That said, we are considering separating the page tables on arm64 since it seems to be relatively easy and unlikely to have a severe impact on performance. Some ARM cores are vulnerable to various Spectre attacks. However since OpenBSD/armv7 flushes the BTB on each context switch already, it is unliekly that other processes can be attached. We're still investigating whether more BTB flushes are necessary. Everything with a Cortex-A7 core should be safe, which is a large fraction of the hardware supported by OpenBSD/armv7. For OpenBSD/arm64 the situation is not so great. Flusihing the BTB there is almost impossible without a firmware update. However, everything with a Cortex-A53 core should be safe, which covers the majority of the hardware supported by OpenBSD/amd64.
Re: Meltdown, aka "Dear Intel, you suck"
> We have received *no* non-public information. I've seen posts elsewhere by > other *BSD people implying that they receive little or no prior warning, so > I have no reason to believe this was specific to OpenBSD and/or our > philosophy. Personally, I do find itamusing? that public announcements > were moved up after the issue was deduced from development discussions and > commits to a different open source OS project. Aren't we all glad that > this was under embargo and strongly believe in the future value of > embargoes? if only the millionares and billionares benefit from receiving information to make improvements to the so-called open and free software stack, then the ecosystem has truly grown up to become captured and will soon gain all the market benefits of other supply chains -- such as ensuring you have inexpensive salmonella spinach on your table from purchased from a smallselection of vendors. But not safety, security, diversity, and choice. Some people should be ashamed of themselves, but they probably purchased options.
Meltdown, aka "Dear Intel, you suck"
So, yes, we the OpenBSD developers are not totally asleep and a handful of us are working out how to deal with Intel's fuck-up aka the Meltdown attack. While we have the advantage of less complexity in this area (e.g., no 32bit-on-64bit compat), there's still a pile of details to work through about what has to be *always* in the page tables vs what can/should/must be hidden. Do KARL or other features of OpenBSD mitigate this? Not particularly. If you're running code from multiple trust domains then yeah, you're largely at risk. We have received *no* non-public information. I've seen posts elsewhere by other *BSD people implying that they receive little or no prior warning, so I have no reason to believe this was specific to OpenBSD and/or our philosophy. Personally, I do find itamusing? that public announcements were moved up after the issue was deduced from development discussions and commits to a different open source OS project. Aren't we all glad that this was under embargo and strongly believe in the future value of embargoes? Unless something unexpected happens, we'll be applying the workaround to amd64 first and then working out what to do for i386 and arm* (if still though to be necessary for arm) after that. No promises on only applying it to Intel CPUs or knobs to disable it, yet: we'll see how complex that would make things. As always, our own developer laptops are the first targets, so we're invested in it working and being usable. Philip Guenther guent...@openbsd.org
