linux-kernel - RE: [RFC PATCH 00/34] x86/bugs: Attack vector controls

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:
 <LV3PR12MB92653FD0D712D0FF24BBE49D94622@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 18 Sep 2024 06:29:40 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
	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: [RFC PATCH 00/34] x86/bugs: Attack vector controls

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> Sent: Tuesday, September 17, 2024 7:04 PM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Borislav Petkov <bp@...en8.de>;
> Peter Zijlstra <peterz@...radead.org>; Josh Poimboeuf
> <jpoimboe@...nel.org>; 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: [RFC PATCH 00/34] x86/bugs: Attack vector controls
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Sep 12, 2024 at 02:08:23PM -0500, David Kaplan wrote:
> > The rest of the patches define new "attack vector" command line
> > options to make it easier to select appropriate mitigations based on
> > the usage of the system.  While many users may not be intimately
> > familiar with the details of these CPU vulnerabilities, they are
> > likely better able to understand the intended usage of their system.
> > As a result, unneeded mitigations may be disabled, allowing users to recoup
> more performance.
>
> How much performance improvement are you seeing with each of the attack
> vector?
>
> There aren't many vulnerabilities that only affect a single attack vector.
> So, selecting to mitigate single attack vector mitigates a lot more than that.

I think any performance discussion will of course vary significantly by microarchitecture, workload, etc.  Several vulnerabilities are known to have non-trivial performance impacts.

Of course it's worth noting that several of the attack vectors likely go hand-in-hand...like if you trust userspace you would disable user_kernel and user_user.  I discuss in patch 18 why these are separated, but at least for now they'd likely be configured in sync.

>
> We may be able to get better performance improvement by adding vector-
> based switches at the mitigation points. And only enable them if user asked for
> it.

Right, and some mitigations might chose to now support different mitigations for each attack vector.  This was already the case with bhi (see patch 30) where the syscall mitigation was enabled only for the user_kernel vector and the vmexit mitigation only for the guest_host vector.  I could imagine other mitigations choosing to support similar separation which could lead to improved performance if mitigations on only certain vectors is required.

--David Kaplan