Message-ID: <20241202121942.GBZ02l3pnKRs51AI-7@fat_crate.local>
Date: Mon, 2 Dec 2024 13:19:42 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Shah, Amit" <Amit.Shah@....com>
Cc: "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
	"corbet@....net" <corbet@....net>,
	"pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
	"kai.huang@...el.com" <kai.huang@...el.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"Lendacky, Thomas" <Thomas.Lendacky@....com>,
	"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
	"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"seanjc@...gle.com" <seanjc@...gle.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"Moger, Babu" <Babu.Moger@....com>,
	"Das1, Sandipan" <Sandipan.Das@....com>,
	"dwmw@...zon.co.uk" <dwmw@...zon.co.uk>,
	"amit@...nel.org" <amit@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"Kaplan, David" <David.Kaplan@....com>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v2 1/2] x86/bugs: Don't fill RSB on VMEXIT with
 eIBRS+retpoline

On Mon, Dec 02, 2024 at 11:15:24AM +0000, Shah, Amit wrote:
> FWIW, I'd say we have fairly decent documentation with commit messages
> + code + comments in code.

You mean everytime we want to swap back in why we did some mitigation decision
the way we did, we should do git archeology and go on a chase?

I've been doing it for years now and it is an awful experience. Absolutely
certainly can be better.
 
> 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.

We need documentation or at least pointers to vendor documentation which
explain why we're doing this exact type of mitigation and why we're not doing
other. Why is it ok to disable SMT, why is it not, for example? This patch is
another good example.

> 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.

Comments within the code are fine. Big fat comment which is almost a page long
is pushing it. It can very well exist in Documentation/ and a short comment
can point to it.

And in Documentation/ we can go nuts and explain away...

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

Why does it look better?

Because of the move of SPECTRE_V2_EIBRS_RETPOLINE?

> 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.

Yes, that's exactly why I'm pushing for improving the documentation and the
reasoning for each mitigation. Exactly because stuff is not under NDA anymore
and we can do all the debating in the open, and the dust has settled.

> This looks like a sound way to go about taking a higher-level view and
> simplifying the code.

Yap.

And to give you another argument for it: when we clean it up nicely, it'll be
easier to add new mitigations. :)

And no, I don't want more but no one's listening to me anyway...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists