[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