Re: Retbleed (RSBA vs BTC)

[Andrew Cooper <Andrew.Cooper3@citrix.com>]

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