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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f68c283c-cfc9-bc63-5d0f-143295a575d4@citrix.com>
Date:   Fri, 15 Jul 2022 01:07:52 +0000
From:   Andrew Cooper <Andrew.Cooper3@...rix.com>
To:     Jim Mattson <jmattson@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Retbleed (RSBA vs BTC)

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