Retbleed (RSBA vs BTC)

Retbleed (RSBA vs BTC)

[Jim Mattson]

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.

Re: Retbleed (RSBA vs BTC)

[Andrew Cooper]

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.

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.

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

~Andrew

Re: Retbleed (RSBA vs BTC)

[Jim Mattson]

On Thu, Jul 14, 2022 at 6:07 PM Andrew Cooper <Andrew.Cooper3@citrix.com> 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.

Re: Retbleed (RSBA vs BTC)

[Andrew Cooper]

On 15/07/2022 21:40, Jim Mattson wrote:
> On Thu, Jul 14, 2022 at 6:07 PM Andrew Cooper <Andrew.Cooper3@citrix.com> 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.

Yeah.  BTC lets you cause a nop to speculate to an arbitrary destination.

This really ought to terrify people more than it appears to have done
thus far...

Retbleed is just the tip of a much larger iceberg.

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

The difference between RRSBA and RSBA is whether eIBRS is active or
not.  According to the current eIBRS documentation.

This is a not-very-subtle hint to Intel that other things needs updating
in order to make their public statements self-consistent.

~Andrew