linux-kernel - Re: Retbleed (RSBA vs BTC)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 15 Jul 2022 22:12:19 +0000
From:   Andrew Cooper <Andrew.Cooper3@...rix.com>
To:     Jim Mattson <jmattson@...gle.com>
CC:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: Retbleed (RSBA vs BTC)

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