From: Daniel Sneddon <daniel.sneddon@linux.intel.com>
To: Borislav Petkov <bp@alien8.de>, Josh Poimboeuf <jpoimboe@kernel.org>
Cc: "Kaplan, David" <David.Kaplan@amd.com>,
Jonathan Corbet <corbet@lwn.net>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pawan.kumar.gupta@linux.intel.com"
<pawan.kumar.gupta@linux.intel.com>
Subject: Re: [PATCH 1/6] x86/bugs: Create single parameter for VERW based mitigations
Date: Mon, 14 Oct 2024 08:42:26 -0700 [thread overview]
Message-ID: <88baaae8-d9fe-4c8a-a5e2-383d6b641e2c@linux.intel.com> (raw)
In-Reply-To: <20241010145737.GOZwfrYaGxCOOlaVhy@fat_crate.local>
On 10/10/24 07:57, Borislav Petkov wrote:
> On Wed, Oct 09, 2024 at 09:52:19PM -0700, Josh Poimboeuf wrote:
>> Is this a realistic use case? Are people really going to want to
>> enable/disable VERW mitigations as a group?
They have to. The way you do it today is by setting four different options. If
you miss one and your system has the bug you missed, too bad, you're getting the
mitigation enabled. Since we have four bugs but only one mitigation, I thought
it made more sense to just have 1 knob to control it rather than 4. However,
since we'd need to keep those old knobs around anyway it turns out we'd just
have 5. :( <insert XKCD comic here>
>
> +1.
>
> David's per-attack-vector stuff will simplify the user side of this
> considerably so I'm trying real-hard to find the point for a new option.
>
> IOW, the reason I requested this cleanup is to have proper sync between the
> different mitigations all using VERW behind the scenes. But there's no need to
> change the user interface, is it?
>
The reason I did the patches this way wasn't so much "need" as it just seemed a
simpler way to do it. Why have 4 knobs when there is really only 1 mitigation
under the hood? My question for you then is what you mean by "proper sync"? I'm
guessing you mean that if any one of those 4 mitigations is set to off then
assume all are off? No one should want to set say, MMIO to =off but RFDS to =on,
so the only real issue is if I set some to =off, but leave others unset, the
unspecified options will default to on, which means all are on. If the desire is
to reverse that so any one of the 4 being disabled is enough to disable all VERW
mitigations, I can make that change. I just want to make sure I know what the
desired path is.
Thanks,
Dan
> Thx.
>
next prev parent reply other threads:[~2024-10-14 15:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 22:31 [PATCH 0/6] VERW based clean-up Daniel Sneddon
2024-09-24 22:31 ` [PATCH 1/6] x86/bugs: Create single parameter for VERW based mitigations Daniel Sneddon
2024-10-08 19:24 ` Kaplan, David
2024-10-09 16:17 ` Daniel Sneddon
2024-10-09 16:36 ` Kaplan, David
2024-10-09 16:39 ` Daniel Sneddon
2024-10-09 19:44 ` Daniel Sneddon
2024-10-09 20:02 ` Kaplan, David
2024-10-09 20:34 ` Daniel Sneddon
2024-10-10 4:52 ` Josh Poimboeuf
2024-10-10 14:57 ` Borislav Petkov
2024-10-14 15:42 ` Daniel Sneddon [this message]
2024-10-15 13:52 ` Borislav Petkov
2024-10-15 14:05 ` Daniel Sneddon
2024-09-24 22:31 ` [PATCH 2/6] x86/bugs: Remove MDS command line Daniel Sneddon
2024-09-24 22:34 ` Dave Hansen
2024-09-24 22:41 ` Daniel Sneddon
2024-09-24 22:31 ` [PATCH 3/6] x86/bugs: Remove TAA kernel parameter Daniel Sneddon
2024-09-24 22:31 ` [PATCH 4/6] x86/bugs: Remove MMIO " Daniel Sneddon
2024-09-24 22:31 ` [PATCH 5/6] x86/bugs: Remove RFDS " Daniel Sneddon
2024-09-24 22:31 ` [PATCH 6/6] x86/bugs: Clean-up verw mitigations Daniel Sneddon
2024-10-02 14:20 ` Nikolay Borisov
2024-10-02 14:46 ` Daniel Sneddon
2024-10-02 14:54 ` Nikolay Borisov
2024-10-07 19:37 ` Josh Poimboeuf
2024-10-08 16:17 ` Daniel Sneddon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=88baaae8-d9fe-4c8a-a5e2-383d6b641e2c@linux.intel.com \
--to=daniel.sneddon@linux.intel.com \
--cc=David.Kaplan@amd.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).