OpenBSD on Zenbleed

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 &quot;major kernels&quot;, vendors or other entities that got a heads up of this vulnerability which happened over two month prior.<p>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).

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 <i>on all the models that we think have the bug</i>” 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].<p>[1]: <a href="https:&#x2F;&#x2F;marc.info&#x2F;?l=openbsd-misc&amp;m=169025404406996&amp;w=2" rel="nofollow noreferrer">https:&#x2F;&#x2F;marc.info&#x2F;?l=openbsd-misc&amp;m=169025404406996&amp;w=2</a><p>[2]: <a href="https:&#x2F;&#x2F;lock.cmpxchg8b.com&#x2F;zenbleed.html#solution" rel="nofollow noreferrer">https:&#x2F;&#x2F;lock.cmpxchg8b.com&#x2F;zenbleed.html#solution</a>

Worth re-posting Theo&#x27;s 2007 note about CPU security bugs again:<p><a href="https:&#x2F;&#x2F;marc.info&#x2F;?l=openbsd-misc&amp;m=118296441702631&amp;w=2" rel="nofollow noreferrer">https:&#x2F;&#x2F;marc.info&#x2F;?l=openbsd-misc&amp;m=118296441702631&amp;w=2</a><p>My hunch is that as they suspected these types of issues is what guided them away from things like AVX and other optimizations.

&gt; <i>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.</i><p>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.

&gt;<i>&quot;OpenBSD does not use the AVX instructions to the same extent that Linux and Microsoft do&quot;</i><p>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&#x27;t implement modern tech advancements like AVX.<p>Not being as vulnerable doesn&#x27;t make OpenBSD more &quot;secure&quot;, it just makes them behind the times - like riding a horse &amp; buggy in a world that&#x27;s quickly evolving to electric vehicles.

My understanding was that Zenbleed code runs in userspace therefore it doesn&#x27;t matter if kernel&#x2F;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.

&quot;OpenBSD does not use the AVX instructions to the same extent that Linux and Microsoft do, so this is not as important.<p>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.&quot;<p>Perhaps I missed something, but it appears musl does not use AVX instructions much if at all.

Remember that the first disk device in the hardware tree (sd0 or wd0) might not be the disk you&#x27;re actually booting from. Take a peek in your dmesg output first before installing new bootblocks to be sure you&#x27;ll be getting the new microcode loader.