OpenBSD on Zenbleed(marc.info) |
OpenBSD on Zenbleed(marc.info) |
Whether they were last to be in the know or not, i applaud them for being one of the first to have patches out for their latest two stable releases (7.2 and 7.3).
[1]: https://marc.info/?l=openbsd-misc&m=169025404406996&w=2
https://marc.info/?l=openbsd-misc&m=118296441702631&w=2
My hunch is that as they suspected these types of issues is what guided them away from things like AVX and other optimizations.
I'm still waiting for benchmarks which show more than a 5% increase in performance with hyper-threading enabled.
Interesting. I would have expected it to be some amount of worse performance not using AVX. Though perhaps the past throttling effects from AVX-512 and friends made it so it was too complex to manage which instructions to select in BSD.
While I love OpenBSD and what they do ... I have to admit, I get frustrated because many times OpenBSD is immune to security vulnerability simply because they don't implement modern tech advancements like AVX.
Not being as vulnerable doesn't make OpenBSD more "secure", it just makes them behind the times - like riding a horse & buggy in a world that's quickly evolving to electric vehicles.
For data to be exfiltrated through this exploit, the sensitive data must first be loaded into an AVX register. On GNU/Linux this happens all the time, because strcmp et al use AVX. On OpenBSD this is not the case, so only applications that themselves are loading sensitive data into AVX registers would be vulnerable.
Anyway, OpenBSD users have the new microcode now, while most Linux users don't (I checked Arch, Fedora and Ubuntu, none of them has updated their packaging yet).
I don't think this is an example of foresight / good design choice, though. They just got lucky that no one cared enough to do performance optimization on their libc string functions.
On Linux, glibc has AVX-based optimizations for simple functions (string and memory copies) which will store secrets into the register file which can be extracted trivially, so the impact on glibc-based systems is HUGE."
Perhaps I missed something, but it appears musl does not use AVX instructions much if at all.
Right, or at least, not explicitly (a sufficiently smart compiler might be able to auto-vectorize it). The author is (reasonably) suggesting that most Linux systems use glibc, rather than musl.
Here's musl:
strlen: https://git.musl-libc.org/cgit/musl/tree/src/string/strlen.c (64-bit words at a time)
memcpy (generic): https://git.musl-libc.org/cgit/musl/tree/src/string/memcpy.c (32-bit copies, unrolled to 4 at a time for a suitably long copy)
(Throwing the generic memcpy into godbolt -O3 shows Clang does choose to implement this in part with XMM and YMM registers: https://godbolt.org/z/dh6hqG77j as does GCC: https://godbolt.org/z/aKraqPaPs )
memcpy (x86_64 asm): https://git.musl-libc.org/cgit/musl/tree/src/string/x86_64/m... (rep movsq -- 64-bit words at a time, implemented by the CPU microcode)
Software running on OpenBSD can clearly use AVX, but the kernel and core OS doesn't yet, which security wise seems to be the smart move.
Look at SMT, that's still disabled on OpenBSD I believe, which indicate that Intel and AMD have yet to devise a way of implementing it safely. You can enable it, if you need the speed more than security, but I doubt that many does.
That's not accurate. OpenBSD does use AVX, it's just very minimal.
What's the "smart move" then here? That OpenBSD just never got around to implementing AVX more thoroughly?
If you're implying that OpenBSD had always considered AVX a security issue, then why are they still having to patch for it (and why did they adopt some use of it)?
Skimming through various OpenBSD mail list, I can't find any past threads discussing their concerns about AVX prior to ZenBleed.
If you chose Open BSD you make that explicit choice. Their promise is to avoid technologies unless they are rock solid, even at the cost of performance or convenience (like the forking to LibreSSL).
So it seems that your statement is only true for the base system.
Those days the web browser is the main path for RCEs on a user's desktop. For example firefox on a linux system uses around 25 external libraries, if not more.
Having such lousy implementation bugs show that at least AMD doesn't care about it anymore, I'd wager there is something better coming round in the near future.
If the performance patches would make the code less secure, they would not implement it.
... unless you need performance. What a vacuous statement!
They've shipped several RCEs over the years, in software included in base, but because the software is not enabled by default they don't update their security slogan.
It gives the impression of an OS that is free of vulns which is not true. The "default install" is not useful for much as IIRC it only has ssh enabled which means their claim of only two remote holes in $time_period is really just a claim against their TCP/IP stack and OpenSSH, not the entire OS.
It's deliberately misleading.
Realistically that probably the right answer, they didn't have the developers nor did they priorities going in and just retro-actively fitting AVX in everywhere where it could potentially help with speed. The "smart choice" deliberately or not, is to not just jump onto everything new but adopt new features at a slower pace.
My reaction was towards against stuff like this:
> I get frustrated because many times OpenBSD is immune to security vulnerability simply because they don't implement modern tech advancements like AVX.
I don't get that. Sure part of it is might not getting around to implementing it, but there's also an implicit choice in not just going in and adopting new features everywhere just because you might need it. OpenBSD developers doesn't seem to have viewed AVX as being something that needed to be prioritized. Otherwise it would have been in more places.
But you're right, they do use AVX, that's clearly a mistake on my part.
So it’s not like AVX is a “new” development. It’s 12-years old.
(Not directing these comments at you. Just trying to expanded upon what drove my original post)
The compilation performance of Rust is also unsatisfying too with right even though it got the package manager right. I remember sitting 15 minutes to build my first ESP32 RISC-V firmware in Rust and still have to wait 2 to 3 minutes for consecutive debug builds. All of that on a Ryzen 3700X, maybe machine issue idk.
But they do have a relatively difficult history with embargoes. This isn't criticising them BTW - although I don't use OpenBSD any more I still have a soft spot for them and respect for everything they've achieved.
See this thread for examples.
https://marc.info/?l=openbsd-tech&m=152909822107104&w=2
More directly, from the KRACK FAQ: As a compromise, I allowed them to silently patch the vulnerability.
https://www.krackattacks.com/#openbsd
It's also worth noting that Microsoft violated the embargo as well: On this topic, it is also worthwhile to mention that Microsoft pushed their fixes on patch Tuesday on 10 October 2016 [1]. That's before the agreed disclosure deadline, albeit quite close in time.
Quite rightly, nobody is suggesting that nearly a decade later, we should be keeping Microsoft off responsible disclosures as a consequence.
The next time you coordinate a disclosure, you can run it differently.