Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CALMp9eS5pBrKWe=LbWXON6bhTdhbX9rB2aF+c-h_a0=SXfyj7A@mail.gmail.com>
 <f68c283c-cfc9-bc63-5d0f-143295a575d4@citrix.com>
In-Reply-To: <f68c283c-cfc9-bc63-5d0f-143295a575d4@citrix.com>
From:   Jim Mattson <jmattson@google.com>
Date:   Fri, 15 Jul 2022 13:40:03 -0700
Message-ID: <CALMp9eSe6dRvSAa6CQp9P_dO5840OqSmhXrS2AabZeCyL_3j=g@mail.gmail.com>
Subject: Re: Retbleed (RSBA vs BTC)
To:     Andrew Cooper <Andrew.Cooper3@citrix.com>
Cc:     LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.