Re: [PATCH v2 1/2] x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline

From: Shah, Amit
Date: Mon Dec 02 2024 - 07:03:38 EST


On Sat, 2024-11-30 at 16:31 +0100, Borislav Petkov wrote:
> On Thu, Nov 21, 2024 at 12:07:18PM -0800, Josh Poimboeuf wrote:
> > eIBRS protects against RSB underflow/poisoning attacks.  Adding
> > retpoline to the mix doesn't change that.  Retpoline has a balanced
> > CALL/RET anyway.
>
> This is exactly why I've been wanting for us to document our
> mitigations for
> a long time now.

FWIW, I'd say we have fairly decent documentation with commit messages
+ code + comments in code.

> A bunch of statements above for which I can only rhyme up they're
> correct if
> I search for the vendor docs. On the AMD side I've found:

[...]

> In any case, I'd like for us to do have a piece of text accompanying
> such
> patches, perhaps here:
>
> Documentation/admin-guide/hw-vuln/spectre.rst
>
> which quotes the vendor docs.

If you're saying that we need *additional* documentation that
replicates hw manuals and the knowledge we have in our commit + code +
comments, that I agree with.

I got the feeling earlier, though, that you were saying we need that
documentation *instead of* the current comments-within-code, and that
didn't sound like the right thing to do.

> The current thread(s) on the matter already show how much confused we
> all are
> by all the possible mitigation options, uarch speculative dances etc
> etc.

... and the code flows and looks much better after this commit (for
SpectreRSB at least), which is a huge plus.

It's important to note that at some point in the past we got
vulnerabilities and hw features/quirks one after the other, and we kept
tacking mitigation code on top of the existing one -- because that's
what you need to do during an embargo period. Now's the moment when
we're consolidating it all while taking stock of the overall situation.
This looks like a sound way to go about taking a higher-level view and
simplifying the code.

I doubt we'd want to do things any other way; and much less doing this
kind of an exercise during an embargo. Moving comments out of the code
will only add to frustration during embargo periods.

Just my 2c

Amit