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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux