Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD on Zenbleed

marc.info

Post reply on HN
Print view View original

51–60 of 64 posts

Re: OpenBSD on Zenbleed

#51

Post by ksec »

pdw wrote: post #3
renewiltord wrote: post #2

> 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. 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 manag…

OpenBSD is not a fast system.

It used to be very slow ( or for some people fast enough ). But I wonder if that is still the case in 2023. This reminded me nagging phoronix to do another BSD reviews.

Re: OpenBSD on Zenbleed

#52

Post by tiffanyh »

mrweasel wrote: post #42
tiffanyh wrote: post #31

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

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 safe…

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

Re: OpenBSD on Zenbleed

#53

Post by hulitu »

binkHN wrote: post #15
RijilV wrote: post #5

Worth re-posting Theo's 2007 note about CPU security bugs again: 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.

OpenBSD was also one of the first operating systems to disable hyper-threading by default due to all the related security issues with this technology. Yet another case of security over speed.

Hyper-threading, at least in the beginning, had limited if any performance improvement when enabled. Windows (XP, 7), at least, was faster at work with hyper-threading disabled.

I'm still waiting for benchmarks which show more than a 5% increase in performance with hyper-threading enabled.

Re: OpenBSD on Zenbleed

#54

Post by mrweasel »

tiffanyh wrote: post #52
mrweasel wrote: post #42

Earlier quoted context omitted.

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 safe…

>"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 havi…

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

Re: OpenBSD on Zenbleed

#56

Post by loeg »

ksec wrote: post #50
ori_b wrote: post #48

Earlier quoted context omitted.

They asked for permission from the coordinator and got it. It's that simple. There's nothing open to interpretation here. The next time you coordinate a disclosure, you can run it differently.

Why do people blame OpenBSD but not the coordinator is beyond me.

This subject of this article is OpenBSD; it's reasonable to be discussing OpenBSD. I'm not saying that guy is blameless.

Re: OpenBSD on Zenbleed

#57

Post by tiffanyh »

mrweasel wrote: post #54
tiffanyh wrote: post #52

Earlier quoted context omitted.

>"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 havi…

> 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 towa…

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

Re: OpenBSD on Zenbleed

#58

Post by loeg »

hulitu wrote: post #53
binkHN wrote: post #15

Earlier quoted context omitted.

OpenBSD was also one of the first operating systems to disable hyper-threading by default due to all the related security issues with this technology. Yet another case of security over speed.

Hyper-threading, at least in the beginning, had limited if any performance improvement when enabled. Windows (XP, 7), at least, was faster at work with hyper-threading disabled. I'm still waiting for benchmarks which show more than a 5% increase in performance with hyper-threading enabled.

If you haven't seen a >5% performance improvement for any workload with HT/SMT enabled, you're just willfully blinding yourself to benchmark data. It can be closer to 80% than 5%, at least for some reasonable workloads.

Re: OpenBSD on Zenbleed

#59

Post by loeg »

ninjin wrote: post #43
saagarjha wrote: post #41

Earlier quoted context omitted.

They also have a limited number of developers and no interest in performance.

“[N]o interest in performance” is probably a bit unfair, no? It makes it sound like any patch that brought solely performance would be rejected. But it is certainly true that they have much less manpower than the “competition” and that performance takes a backseat relative to other priorities.

No, it's fair -- they're actively disinterested in patches that improve performance.

Re: OpenBSD on Zenbleed

#60

Post by loeg »

1vuio0pswjnm7 wrote: post #32

"OpenBSD does not use the AVX instructions to the same extent that Linux and Microsoft do, so this is not as important. 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 m…

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

Post reply on HN