From: "Manwaring, Derek" <derekmn@amazon.com>
To: <david.kaplan@amd.com>
Cc: <bp@alien8.de>, <dave.hansen@intel.com>,
<dave.hansen@linux.intel.com>, <hpa@zytor.com>,
<jpoimboe@kernel.org>, <linux-kernel@vger.kernel.org>,
<mingo@redhat.com>, <pawan.kumar.gupta@linux.intel.com>,
<peterz@infradead.org>, <tglx@linutronix.de>, <x86@kernel.org>
Subject: RE: [RFC PATCH 27/34] x86/bugs: Add attack vector controls for spectre_v1
Date: Mon, 30 Sep 2024 17:39:55 -0700 [thread overview]
Message-ID: <9de4f491-eb64-4a1e-a375-7bc2d382fe5e@amazon.com> (raw)
In-Reply-To: <LV3PR12MB926575E4BB94AE51EA662A3694642@LV3PR12MB9265.namprd12.prod.outlook.com>
On 2024-09-12 21:15+0000 David Kaplan wrote:
> On 2024-09-12 13:16-0700 Dave Hansen wrote:
> > On 9/12/24 12:57, Kaplan, David wrote:
> > > And to be clear, I was trying to continue to support both. But the
> > > attack-vector style is also more future-proof because when new issues
> > > arise, they would get added to the appropriate vectors and users
> > > wouldn't have to do anything ideally.
> >
> > That's a good point. Do you have any inkling about how static folks'
> > vector selection would have been over time?
> >
> > For instance, if someone cared about CPU_MITIGATE_GUEST_HOST at the
> > original spectre_v2 time, did that carry forward to L1TF and all the way into
> > 2024?
> >
> > Or would they have had to shift their vector selection over time?
>
> In my view, the attack vector selection is a function of how the system
> is being used. A system that runs untrusted guests and cared about
> spectre_v2 I would think also cares about L1TF, Retbleed, etc. They're
> all attacks that can leak the same kind of data, although the mechanisms
> of exploit are different. In what I've personally seen, if you care
> about one attack along a certain attack vector, you tend to care about
> all of them.
This makes sense, but I'm not sure it is a meaningful simplification for
users. I think it'd be helpful if we had a few samples of how users
normally configure their systems. My hunch would be there are three main
camps:
1) default for everything
2) mitigations=off
3) specify at least one mitigation individually.
I think you're saying group (3) is helped most because now they don't
have to understand each individual mitigation. But (3) is perhaps
already a very small group of users? Maybe it would help (1) as well
because they would get performance gains, but I'm skeptical of how many
would feel safe switching from defaults to a vector specification. If
they do feel comfortable doing that, they're probably closer to (3). Is
that fair?
Derek
next prev parent reply other threads:[~2024-10-01 0:39 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 19:08 [RFC PATCH 00/34] x86/bugs: Attack vector controls David Kaplan
2024-09-12 19:08 ` [RFC PATCH 01/34] x86/bugs: Relocate mds/taa/mmio/rfds defines David Kaplan
2024-10-24 13:07 ` Borislav Petkov
2024-09-12 19:08 ` [RFC PATCH 02/34] x86/bugs: Add AUTO mitigations for mds/taa/mmio/rfds David Kaplan
2024-09-12 19:08 ` [RFC PATCH 03/34] x86/bugs: Restructure mds mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 04/34] x86/bugs: Restructure taa mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 05/34] x86/bugs: Restructure mmio mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 06/34] x86/bugs: Restructure rfds mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 07/34] x86/bugs: Remove md_clear_*_mitigation() David Kaplan
2024-10-08 8:40 ` Nikolay Borisov
2024-09-12 19:08 ` [RFC PATCH 08/34] x86/bugs: Restructure srbds mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 09/34] x86/bugs: Restructure gds mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 10/34] x86/bugs: Restructure spectre_v1 mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 11/34] x86/bugs: Restructure retbleed mitigation David Kaplan
2024-10-08 8:32 ` Nikolay Borisov
2024-10-08 14:28 ` Kaplan, David
2024-09-12 19:08 ` [RFC PATCH 12/34] x86/bugs: Restructure spectre_v2_user mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 13/34] x86/bugs: Restructure bhi mitigation David Kaplan
2024-10-08 12:41 ` Nikolay Borisov
2024-10-08 14:25 ` Kaplan, David
2024-09-12 19:08 ` [RFC PATCH 14/34] x86/bugs: Restructure spectre_v2 mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 15/34] x86/bugs: Restructure ssb mitigation David Kaplan
2024-10-08 15:21 ` Nikolay Borisov
2024-09-12 19:08 ` [RFC PATCH 16/34] x86/bugs: Restructure l1tf mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 17/34] x86/bugs: Restructure srso mitigation David Kaplan
2024-09-12 19:08 ` [RFC PATCH 18/34] Documentation/x86: Document the new attack vector controls David Kaplan
2024-10-01 0:43 ` Manwaring, Derek
2024-10-01 1:53 ` Kaplan, David
2024-10-01 22:21 ` Manwaring, Derek
2024-09-12 19:08 ` [RFC PATCH 19/34] x86/bugs: Define attack vectors David Kaplan
2024-09-12 19:08 ` [RFC PATCH 20/34] x86/bugs: Determine relevant vulnerabilities based on attack vector controls David Kaplan
2024-09-12 19:08 ` [RFC PATCH 21/34] x86/bugs: Add attack vector controls for mds David Kaplan
2024-10-01 0:50 ` Manwaring, Derek
2024-10-01 1:58 ` Kaplan, David
2024-10-01 22:37 ` Manwaring, Derek
2024-10-02 14:28 ` Kaplan, David
2024-10-02 20:11 ` Manwaring, Derek
2024-10-02 20:26 ` Kaplan, David
2024-10-02 15:50 ` Pawan Gupta
2024-10-02 19:40 ` Manwaring, Derek
2024-09-12 19:08 ` [RFC PATCH 22/34] x86/bugs: Add attack vector controls for taa David Kaplan
2024-09-12 19:08 ` [RFC PATCH 23/34] x86/bugs: Add attack vector controls for mmio David Kaplan
2024-09-12 19:08 ` [RFC PATCH 24/34] x86/bugs: Add attack vector controls for rfds David Kaplan
2024-09-12 19:08 ` [RFC PATCH 25/34] x86/bugs: Add attack vector controls for srbds David Kaplan
2024-09-12 19:08 ` [RFC PATCH 26/34] x86/bugs: Add attack vector controls for gds David Kaplan
2024-09-12 19:08 ` [RFC PATCH 27/34] x86/bugs: Add attack vector controls for spectre_v1 David Kaplan
2024-09-12 19:37 ` Dave Hansen
2024-09-12 19:57 ` Kaplan, David
2024-09-12 20:16 ` Dave Hansen
2024-09-12 21:15 ` Kaplan, David
2024-10-01 0:39 ` Manwaring, Derek [this message]
2024-10-01 1:46 ` Kaplan, David
2024-10-01 22:18 ` Manwaring, Derek
2024-09-13 14:20 ` Borislav Petkov
2024-09-12 19:08 ` [RFC PATCH 28/34] x86/bugs: Add attack vector controls for retbleed David Kaplan
2024-09-12 19:08 ` [RFC PATCH 29/34] x86/bugs: Add attack vector controls for spectre_v2_user David Kaplan
2024-09-12 19:08 ` [RFC PATCH 30/34] x86/bugs: Add attack vector controls for bhi David Kaplan
2024-09-12 19:08 ` [RFC PATCH 31/34] x86/bugs: Add attack vector controls for spectre_v2 David Kaplan
2024-09-12 19:08 ` [RFC PATCH 32/34] x86/bugs: Add attack vector controls for l1tf David Kaplan
2024-09-12 19:08 ` [RFC PATCH 33/34] x86/bugs: Add attack vector controls for srso David Kaplan
2024-09-12 19:08 ` [RFC PATCH 34/34] x86/pti: Add attack vector controls for pti David Kaplan
2024-09-17 17:04 ` [RFC PATCH 00/34] x86/bugs: Attack vector controls Pawan Gupta
2024-09-18 6:29 ` Kaplan, David
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=9de4f491-eb64-4a1e-a375-7bc2d382fe5e@amazon.com \
--to=derekmn@amazon.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david.kaplan@amd.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@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
Powered by JetHome