I wrote an article about a bug I found on AMD Zen2. The problem is that
a speculatively executed VZEROUPPER instruction will not be rolled back
correctly on branch misprediction:

https://lock.cmpxchg8b.com/zenbleed.html

Essentially, a code sequence like this:

vcvtsi2s{s,d} xmm, xmm, r64
vmovdqa ymm, ymm
jcc overzero
vzeroupper
overzero:
nop

There's a microcode patch available (or a chicken bit).

I thought this group might be interested in the details!

Tavis.

--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@sdf.org
_\_V _( ) _( ) @taviso

Tavis Ormandy <taviso@gmail.com> writes:
>I wrote an article about a bug I found on AMD Zen2. The problem is that
>a speculatively executed VZEROUPPER instruction will not be rolled back
>correctly on branch misprediction:
>
>https://lock.cmpxchg8b.com/zenbleed.html
>
>Essentially, a code sequence like this:
>
> vcvtsi2s{s,d} xmm, xmm, r64
> vmovdqa ymm, ymm
> jcc overzero
> vzeroupper
> overzero:
> nop
>
>There's a microcode patch available (or a chicken bit).
>
>I thought this group might be interested in the details!

Thanks for turning up here yourself. I found your blog posting
through some web site, and expected someone to mention it here, but it
did not happen. I myself wanted to check what the xmm merge
optimization is before writing anything.

What I find most interesting about this vulnerability is that it
extracts speculatively-gotten material not through a side channel, but
through architectural state, i.e., the main channel. This is OoO CPU
design 101, and they should have gotten it right (and apparently got
it right for Zen 3; I wonder if the Zen 2 bug was noticed at some
point, or if the lack of this vulnerability on Zen 3 is just due to
redesign without noticing that something is amiss.

What is also interesting is that despite this being an architecturally
visible bug, apparently nobody noticed it when doing ordinary
programming. You found it through fuzzing.

Your fuzzing technique for architectural bugs is also quite
interesting. Did you expect to find some?

What does the DE_CFG[9] chicken bit disable?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Wednesday, August 2, 2023 at 12:53:31 PM UTC-5, Anton Ertl wrote:
> Tavis Ormandy <tav...@gmail.com> writes:
> >I wrote an article about a bug I found on AMD Zen2. The problem is that
> >a speculatively executed VZEROUPPER instruction will not be rolled back
> >correctly on branch misprediction:
> >
> >https://lock.cmpxchg8b.com/zenbleed.html
> >
> >Essentially, a code sequence like this:
> >
> > vcvtsi2s{s,d} xmm, xmm, r64
> > vmovdqa ymm, ymm
> > jcc overzero
> > vzeroupper
> > overzero:
> > nop
> >
> >There's a microcode patch available (or a chicken bit).
> >
> >I thought this group might be interested in the details!
<
> Thanks for turning up here yourself. I found your blog posting
> through some web site, and expected someone to mention it here, but it
> did not happen. I myself wanted to check what the xmm merge
> optimization is before writing anything.
>
> What I find most interesting about this vulnerability is that it
> extracts speculatively-gotten material not through a side channel, but
> through architectural state, i.e., the main channel. This is OoO CPU
> design 101, and they should have gotten it right (and apparently got
> it right for Zen 3; I wonder if the Zen 2 bug was noticed at some
> point, or if the lack of this vulnerability on Zen 3 is just due to
> redesign without noticing that something is amiss.
<
Back in 1983 when we first started designing Mc 88100 we had a rule
whereby if any bit of a register* is modified, then all of the bits of that
register are modified.
<
Had this rule been considered, this bug would not have manifest itself.
<
(*) GPR, FPR, CC, PTE, .....
>
> What is also interesting is that despite this being an architecturally
> visible bug, apparently nobody noticed it when doing ordinary
> programming. You found it through fuzzing.
<
This is a side effect of throwing in more instructions per generation
than you can verify. It probably got lost in some vast vector of new
instruction additions.
>
> Your fuzzing technique for architectural bugs is also quite
> interesting. Did you expect to find some?
>
> What does the DE_CFG[9] chicken bit disable?
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>