linux-kernel - Re: [PATCH v6 00/13] x86/bugs: Add a separate config for each mitigation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 10 Jan 2024 03:55:44 -0800
From: Breno Leitao <leitao@...ian.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: jpoimboe@...nel.org, mingo@...hat.com, tglx@...utronix.de, bp@...en8.de,
	x86@...nel.org, leit@...a.com, linux-kernel@...r.kernel.org,
	pawan.kumar.gupta@...ux.intel.com, bpf@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v6 00/13] x86/bugs: Add a separate config for each
 mitigation

On Wed, Jan 10, 2024 at 10:56:46AM +0100, Ingo Molnar wrote:
> 
> * Breno Leitao <leitao@...ian.org> wrote:
> 
> > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated,
> > where some mitigations have entries in Kconfig, and they could be
> > modified, while others mitigations do not have Kconfig entries, and
> > could not be controlled at build time.
> > 
> > The fact of having a fine grained control can help in a few ways:
> > 
> > 1) Users can choose and pick only mitigations that are important for
> > their workloads.
> > 
> > 2) Users and developers can choose to disable mitigations that mangle
> > the assembly code generation, making it hard to read.
> > 
> > 3) Separate configs for just source code readability,
> > so that we see *which* butt-ugly piece of crap code is for what
> > reason.
> > 
> > Important to say, if a mitigation is disabled at compilation time, it
> > could be enabled at runtime using kernel command line arguments.
> > 
> > Discussion about this approach:
> > https://lore.kernel.org/all/CAHk-=wjTHeQjsqtHcBGvy9TaJQ5uAm5HrCDuOD9v7qA9U1Xr4w@mail.gmail.com/
> > and
> > https://lore.kernel.org/lkml/20231011044252.42bplzjsam3qsasz@treble/
> > 
> > In order to get the missing mitigations, some clean up was done.
> > 
> > 1) Get a namespace for mitigations, prepending MITIGATION to the Kconfig
> > entries.
> > 
> > 2) Adding the missing mitigations, so, the mitigations have entries in the
> > Kconfig that could be easily configure by the user.
> > 
> > With this patchset applied, all configs have an individual entry under
> > CONFIG_SPECULATION_MITIGATIONS, and all of them starts with CONFIG_MITIGATION.
> 
> Yeah, so:
> 
>  - I took this older series and updated it to current upstream, and made
>    sure all renames were fully done: there were two new Kconfig option
>    uses, which I integrated into the series. (Sorry about the delay, holiday & stuff.)
> 
>  - I also widened the renames to comments and messages, which were not
>    always covered.
> 
>  - Then I took this cover letter and combined it with a more high level
>    description of the reasoning behind this series I wrote up, and added it
>    to patch #1. (see it below.)
> 
>  - Then I removed the changelog repetition from the other patches and just
>    referred them back to patch #1.
> 
>  - Then I stuck the resulting updated series into tip:x86/bugs, without the 
>    last 3 patches that modify behavior.

Thanks for your work. I am currently reviwing the tip branch and the
merge seems go so far.

Regarding the last 3 patches, what are the next steps?

Thank you!
Breno