What is the value in conflating the Intel and AMD findings under the
same moniker (arch/x86/kernel/cpu/common.c)? The vulnerabilities seem
quite different to me.
The Intel CPUs tagged with RETBLEED should already report RSBA. The
paper just highlights this previously disclosed vulnerability. Or are
there Intel CPUs subject to Retbleed that don't report RSBA, and I'm
just confused?
On the AMD side, however, Branch Type Confusion is a much bigger deal.
All instructions are subject to steering by BTI, not just returns with
an empty RSB.
Don't these two vulnerabilities deserve separate names (and don't we
already have a name for the first one)?
Tangentially, I believe that the following line is wrong:
VULNBL_INTEL_STEPPINGS(SKYLAKE_X, X86_STEPPING_ANY, MMIO | RETBLEED),
Steppings 5, 6, and 7 are "Cascade Lake," with eIBRS, and I don't
think Cascade Lake suffers from RSBA.
On Thu, Jul 14, 2022 at 6:07 PM Andrew Cooper <[email protected]> wrote:
>
> On 15/07/2022 01:29, Jim Mattson wrote:
> > What is the value in conflating the Intel and AMD findings under the
> > same moniker (arch/x86/kernel/cpu/common.c)? The vulnerabilities seem
> > quite different to me.
>
> They are entirely different, beyond the fact that they both pertain to
> the `ret` instruction.
BTC affects much more than just the 'ret' instruction.
> Suffice it to say that I tried very hard to prevent this confusion...
>
> > The Intel CPUs tagged with RETBLEED should already report RSBA. The
> > paper just highlights this previously disclosed vulnerability. Or are
> > there Intel CPUs subject to Retbleed that don't report RSBA, and I'm
> > just confused?
>
> There are CPUs which suffer from RSBA, that don't have MSR_ARCH_CAPS and
> therefore can't enumerate it.
>
> IIRC, MSR_ARCH_CAPS only appeared with Cascade Lake (or thereabouts), so
> the earlier Skylake CPUs (which are the majority subject of "Intel
> Retbleed") lack the RSBA enumeration.
Ah, right. I was thinking that we got IA32_ARCH_CAPABILITIES on older
parts with microcode updates, but I was mistaken.
> > On the AMD side, however, Branch Type Confusion is a much bigger deal.
> > All instructions are subject to steering by BTI, not just returns with
> > an empty RSB.
> >
> > Don't these two vulnerabilities deserve separate names (and don't we
> > already have a name for the first one)?
> >
> > Tangentially, I believe that the following line is wrong:
> > VULNBL_INTEL_STEPPINGS(SKYLAKE_X, X86_STEPPING_ANY, MMIO | RETBLEED),
> >
> > Steppings 5, 6, and 7 are "Cascade Lake," with eIBRS, and I don't
> > think Cascade Lake suffers from RSBA.
>
> As documented, Cascade Lake does suffer RSBA when eIBRS isn't active, so
> it's not a binary affliction state.
Is there no value in separating RRSBA from RSBA? Per Table 1 in
Intel's "Return Stack Buffer Underflow" technical paper, Cascade Lake
exhibits RRSBA behavior, but not RSBA behavior.