Hacker News new | ask | show | jobs
by tiffanyh 1066 days ago
>"OpenBSD does not use the AVX instructions to the same extent that Linux and Microsoft do"

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.

4 comments

You could also read it as "Other operating systems are way to quick to adopt new features without fully considering the security ramification".

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.

>"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."

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.

https://www.openbsd.org/mail.html

> That OpenBSD just never got around to implementing AVX more thoroughly?

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.

FWIW, my original post was mainly fueled by the fact that AVX was announced in 2008 and in both Intel & AMD chips by 2011.

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)

https://en.m.wikipedia.org/wiki/Advanced_Vector_Extensions

That's honestly also a little older than I expected. It is a little weird I'll admit. It would be interesting to know if the slow adoption in OpenBSD is deliberate or done on purpose.
You might need a box to be as safe as possible, but performance is secondary. Following your car example, some people prefer a safer car over a faster one.

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).

> While working on our fixes, I ran the test programs for quite a while and I never saw anything resembling a 'text' string. However when I ran a browser I saw streams of what was probably graphics-related fragments flowing past. The base system clearly uses AVX very rarely by itself.

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.

Or that just mean the rest of the industry is careless about their security and unrespectful of their users and prefer racing the marketing and performance arm race.
More like a walkable city in a world that is quickly devolving into noisy, polluted, car-dependent cities. You may find that over a decade or a few hundred years negative externalities of a technical decision outweigh the benefits. When AVX dies a painful death in the next decade, projects like OpenBSD won't feel as much pain from it.

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 you think AVX will die “a painful death in the next decade” you’re not really in a good position to call AMD’s implementation lousy.
I think this is a bit short sighted. In the end, x86 will be replaced entirely, should openbsd just ditch it altogether?