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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 15 Jul 2022 13:40:03 -0700
From:   Jim Mattson <jmattson@...gle.com>
To:     Andrew Cooper <Andrew.Cooper3@...rix.com>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: Retbleed (RSBA vs BTC)

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.

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