Messages in this thread | | | From | Andrew Cooper <> | Subject | Re: Retbleed (RSBA vs BTC) | Date | Fri, 15 Jul 2022 22:12:19 +0000 |
| |
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
| |