[MODERATED] Re: [PATCH v2 1/2] v2: more sampling fun 1

mark gross <[email protected]> Wed, 26 Feb 2020 14:11:02 -0800
Newsgroups org.kernel.lore.historical-speck
Message-ID <[email protected]>
On Wed, Feb 26, 2020 at 06:59:50PM +0100, speck for Borislav Petkov wrote:
> On Wed, Feb 26, 2020 at 09:11:03AM -0800, speck for mark gross wrote:
> > Yeah, Andi pointed it out to me on an internal review.  I don't know what tool
> > is using it.
> 
> Then how do you write a patch and state in the commit message that
> something is an ABI without knowing what the situation actually is?!
Easily, I trusted Andi's feedback.  I'm good with it as I think he initially
created that data structure.  I'll get specific user mode users of the
structure and call it out in the commit comment for the next version.

> 
> > FWIW doing it this way made a cleaner patch without touching a dozen other
> > files using that structure.  I'd rather stay with the way it is but, if you
> > feel strongly I can do a version of what I had before only adding the new
> > members to the end.  Please let me know.
> 
> Looking at that table again - cpu_vuln_whitelist - that is a
> *whitelist*. See how all the bits start with "NO_"? Except maybe
> MSBDS_ONLY.
> 
> What you're doing is, you're misusing it to match models and steppings
> to set SRBDS* bug flags.
> 
> What you should actually be doing is setting those bug flags in
> early_init_intel() where you can go wild with the steppings checking and
> then you won't need to touch x86_cpu_id at all.

I can certainly make a new table elsewhere if you want all the special case /
hard-coded vulnerabilities spread around the kernel source tree as opposed to
one centralized place.

--mark