[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZRV1bIuSXjZ+uPKB@gmail.com>
Date: Thu, 28 Sep 2023 05:45:32 -0700
From: Breno Leitao <leitao@...ian.org>
To: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Cc: leit@...a.com,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] x86/bugs: Add a separate config for each mitigation
On Wed, Jun 28, 2023 at 07:21:28AM -0700, leitao@...ian.org wrote:
> From: Breno Leitao <leitao@...ian.org>
>
> Create an entry for each CPU mitigation under
> CONFIG_SPECULATION_MITIGATIONS. This allow users to enable or disable
> them at compilation time.
>
> If a mitigation is disabled at compilation time, it could be enabled at
> runtime using kernel command line arguments.
I had a chat about this topic with Boris and Thomas at Kernel Recipes,
and I would like to summarize the current state, and get it moving
forward.
1) The hardware mitigations are half-way added to KCONFIG. I.e., half of
the hardware mitigations are specified under SPECULATION_MITIGATIONS,
but not all of them.
* You can enabled/disabled just half of them at build time.
2) It is impossible to build a kernel with speculative mitigations
disabled.
* The only way to disable the mitigations is at boot time,
using the "mitigations=off" boot parameter.
So, disabling SPECULATION_MITIGATIONS, will only disable the mitigations
that are under SPECULATION_MITIGATIONS. Other mitigations will continue
to be enabled by default. This is is misleading for the user.
Here are a few options moving forward:
1) Create one Kconfig entry per mitigation, so, the user can pick and
choose what to enable and disable. (Version 3 of this patch. May need a
re-spin due to the new mitigations being added.)
2) Keep the Kconfig entries as-is. Create a new Kconfig entry
(CPU_MITIGATIONS_DEFAULT_OFF?) to disable the mitigations by default,
similarly to the `mitigations=off` boot parameter (v1 of this patch)
3) Same as 2, but, reusing SPECULATION_MITIGATIONS instead of
creating a new Kconfig entry.
4) Remove the current entries in SPECULATION_MITIGATIONS and the fine
control on what to enable/disable?!
What is the preferred way?
Powered by blists - more mailing lists