linux-kernel - RE: [PATCH v2 20/35] x86/bugs: Define attack vectors

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]

Message-ID:
 <LV3PR12MB9265CDD0B551A0F06F64417994152@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Fri, 3 Jan 2025 15:29:03 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>
CC: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra
	<peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>, Pawan Gupta
	<pawan.kumar.gupta@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, Dave
 Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H .
 Peter Anvin" <hpa@...or.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 20/35] x86/bugs: Define attack vectors

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Friday, January 3, 2025 9:19 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Peter Zijlstra <peterz@...radead.org>;
> Josh Poimboeuf <jpoimboe@...nel.org>; Pawan Gupta
> <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar <mingo@...hat.com>; Dave
> Hansen <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> <hpa@...or.com>; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2 20/35] x86/bugs: Define attack vectors
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Tue, Nov 05, 2024 at 03:54:40PM -0600, David Kaplan wrote:
> > diff --git a/kernel/cpu.c b/kernel/cpu.c index
> > d0699e47178b..841bcffee5d3 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
>
> I faintly remember talking about this but shouldn't we make those vectors x86-only
> for now?
>
> No need to have them in generic code as other arches will need to get enabled first
> anyway so they can lift them here when they need them.

The concept of attack vectors are generic (like how mitigations=off is generic), while the bugs involved are arch-specific.  Other architectures support speculative mitigations too (for many of the same bugs), but I'm not enough of an expert in those architectures personally to implement/document attack vector controls for them.  It shouldn't be too hard though for someone who knows them better.

Imo, keeping them in generic code is more forward-looking and prevents the next developer from having to move them back here once another architecture implements them.  But I can move them to bugs.c if that is the preference...

>
> > @@ -3200,6 +3200,22 @@ enum cpu_mitigations {
> >
> >  static enum cpu_mitigations cpu_mitigations __ro_after_init =
> > CPU_MITIGATIONS_AUTO;
> >
> > +/*
> > + * All except the cross-thread attack vector are mitigated by default.
> > + * Cross-thread mitigation often requires disabling SMT which is too
> > +expensive
> > + * to be enabled by default.
> > + *
> > + * Guest-to-Host and Guest-to-Guest vectors are only needed if KVM
> > +support is
> > + * present.
> > + */
> > +static bool cpu_mitigate_attack_vectors[NR_CPU_ATTACK_VECTORS]
> __ro_after_init = {
> > +     [CPU_MITIGATE_USER_KERNEL] = true,
> > +     [CPU_MITIGATE_USER_USER] = true,
> > +     [CPU_MITIGATE_GUEST_HOST] = IS_ENABLED(CONFIG_KVM),
> > +     [CPU_MITIGATE_GUEST_GUEST] = IS_ENABLED(CONFIG_KVM),
> > +     [CPU_MITIGATE_CROSS_THREAD] = false };
> > +
> >  static int __init mitigations_parse_cmdline(char *arg)  {
> >       if (!strcmp(arg, "off"))
> > @@ -3228,11 +3244,53 @@ bool cpu_mitigations_auto_nosmt(void)
> >       return cpu_mitigations == CPU_MITIGATIONS_AUTO_NOSMT;  }
> > EXPORT_SYMBOL_GPL(cpu_mitigations_auto_nosmt);
> > +
> > +#define DEFINE_ATTACK_VECTOR(opt, v) \ static int __init
> > +v##_parse_cmdline(char *arg) \ { \
> > +     if (!strcmp(arg, "off")) \
> > +             cpu_mitigate_attack_vectors[v] = false; \
> > +     else if (!strcmp(arg, "on")) \
> > +             cpu_mitigate_attack_vectors[v] = true; \
> > +     else \
> > +             pr_warn("Unsupported " opt "=%s\n", arg); \
> > +     return 0; \
> > +} \
> > +early_param(opt, v##_parse_cmdline)
> > +
> > +bool cpu_mitigate_attack_vector(enum cpu_attack_vectors v) {
> > +     BUG_ON(v >= NR_CPU_ATTACK_VECTORS);
>
> Yeah, we don't love BUG* at all if it can be helped without it. And here it can. You
> can simply return false for out-of-range vector and WARN_ON_ONCE.
>

Ack.

--David Kaplan