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

21–30 of 64 posts

Re: OpenBSD on Zenbleed

#21

Post by ori_b »

antod wrote: post #13
slome wrote: post #12

OpenBSD only implemented loading AMD firmware two days after AMD published updated microcode to fix Zenbleed. Which makes me believe they were not among the "major kernels", vendors or other entities that got a heads up of this vulnerability which happened over two month prior. 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 re…

Don't know if it was still the case, but OpenBSD would not get early vuln info because they wouldn't sit on embargoes and would patch right away.

This is untrue. OpenBSD pushes to release as early as possible, but if they're on an embargo, they've respected it.

Re: OpenBSD on Zenbleed

#22

Post by loeg »

oskarw85 wrote: post #14

My understanding was that Zenbleed code runs in userspace therefore it doesn't matter if kernel/libraries use AVX optimizations or not. That jab against Linux sounds like blame shifting and moving discussion away from the fact that OpenBSD did not offer microcode update at all.

Zenbleed's impact is due to userspace (including library) use of AVX registers. Glibc is part of userspace. OpenBSD libc is not glibc. It's a valid difference.

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.

Re: OpenBSD on Zenbleed

#23

Post by loeg »

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…

Yes, it does come with worse performance (for those functions).

Re: OpenBSD on Zenbleed

#24

Post by loeg »

ori_b wrote: post #21
antod wrote: post #13

Earlier quoted context omitted.

Don't know if it was still the case, but OpenBSD would not get early vuln info because they wouldn't sit on embargoes and would patch right away.

This is untrue. OpenBSD pushes to release as early as possible, but if they're on an embargo, they've respected it.

Eh, it's more or less true. OpenBSD violated the KRACK embargo in 2018. They decided to publish for the benefit of their users, and fuck everyone else.

Re: OpenBSD on Zenbleed

#25

Post by antod »

ori_b wrote: post #21
antod wrote: post #13

Earlier quoted context omitted.

Don't know if it was still the case, but OpenBSD would not get early vuln info because they wouldn't sit on embargoes and would patch right away.

This is untrue. OpenBSD pushes to release as early as possible, but if they're on an embargo, they've respected it.

Technically correct I suppose - https://isopenbsdsecu.re/mitigations/embargoes_handling/

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.

Re: OpenBSD on Zenbleed

#26

Post by [deleted] »

loeg wrote: post #24
ori_b wrote: post #21

Earlier quoted context omitted.

This is untrue. OpenBSD pushes to release as early as possible, but if they're on an embargo, they've respected it.

Eh, it's more or less true. OpenBSD violated the KRACK embargo in 2018. They decided to publish for the benefit of their users, and fuck everyone else.

[deleted]

Re: OpenBSD on Zenbleed

#27

Post by ori_b »

loeg wrote: post #24
ori_b wrote: post #21

Earlier quoted context omitted.

This is untrue. OpenBSD pushes to release as early as possible, but if they're on an embargo, they've respected it.

Eh, it's more or less true. OpenBSD violated the KRACK embargo in 2018. They decided to publish for the benefit of their users, and fuck everyone else.

Incorrect. They had explicit permission from the researcher involved to commit when they did. Here's the full discussion, if you want to read it yourself.

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.

Re: OpenBSD on Zenbleed

#28

Post by ori_b »

antod wrote: post #25
ori_b wrote: post #21

Earlier quoted context omitted.

This is untrue. OpenBSD pushes to release as early as possible, but if they're on an embargo, they've respected it.

Technically correct I suppose - https://isopenbsdsecu.re/mitigations/embargoes_handling/ 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.

Rather difficult, in the sense that people continue spreading falsehoods about their relationship with embargoes, which makes it difficult to participate in responsible disclosure.

See this thread for examples.

Re: OpenBSD on Zenbleed

#29

Post by ninjin »

There is further information from de Raadt on impact and mitigations [1]. Hearing that the microcode fixes from AMD does not cover all CPUs that are likely to be vulnerable is not great. Reading “[W]e are setting DE_CFG bit 9 on all the models that we think have the bug” is comforting and exactly what I would expect from the OpenBSD developers, as it follows what happened back around Heartbleed and it is one of the workarounds mentioned by the Zenbleed security researchers [2].

[1]: https://marc.info/?l=openbsd-misc&m=169025404406996&w=2

[2]: https://lock.cmpxchg8b.com/zenbleed.html#solution

Re: OpenBSD on Zenbleed

#30

Post by loeg »

ori_b wrote: post #27
loeg wrote: post #24

Earlier quoted context omitted.

Eh, it's more or less true. OpenBSD violated the KRACK embargo in 2018. They decided to publish for the benefit of their users, and fuck everyone else.

Incorrect. They had explicit permission from the researcher involved to commit when they did. Here's the full discussion, if you want to read it yourself. 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:…

I mean, I just disagree with that interpretation of 2018 events. The embargo deadline was extended, OpenBSD violated that. They refused to play ball with the coordinated extension. The researcher is orthogonal to that. Their actions in 2018 are certainly not universally celebrated as a good way to participate in an embargo.
Post reply on HN