linux-kernel - Re: [PATCH v2 19/35] Documentation/x86: Document the new 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: <20241106103922.GBZytHWloHcFZ8CNL_@fat_crate.local>
Date: Wed, 6 Nov 2024 11:39:22 +0100
From: Borislav Petkov <bp@...en8.de>
To: David Kaplan <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 19/35] Documentation/x86: Document the new attack
 vector controls

On Tue, Nov 05, 2024 at 03:54:39PM -0600, David Kaplan wrote:
> Document the 5 new attack vector command line options, how they
> interact with existing vulnerability controls, and recommendations on
> when they can be disabled.
> 
> Note that while mitigating against untrusted userspace requires both
> mitigate_user_kernel and mitigate_user_user, these are kept separate.
> The kernel can control what code executes inside of it and that may
> affect the risk associated with vulnerabilities especially if new kernel
> mitigations are implemented.  The same isn't typically true of userspace.
> 
> In other words, the risk associated with user_user or guest_guest
> attacks is unlikely to change over time.  While the risk associated with
> user_kernel or guest_host attacks may change.  Therefore, these controls
> are separated.

Right, and this is one of the thing David and I have been bikeshedding on
recently so perhaps it'll be cool to hear some more opinions.

My issue with this is, because I always try to make the user interface as
simple as possible, I'm wondering if we should merge

	user_kernel and user_user

and

	guest_host and guest_guest

each into a single option.

Because user_user and guest_guest each pull in user_kernel and guest_host
respectively, due to how the protections work.

As David says, what user_kernel and guest_host enable for mitigating the
respective vector, will change when we add more involved kernel protection
schemes so their overhead should potentially go down.

While the user_user and guest_guest things should not change that much.

So, provided we always DTRT, what gets enabled behind those vectors will
change but still be sufficient depending on the kernel and its protections.

One of the arguments against those getting merged is, those are not going to
be *vector* controls anymore but something else:

mitigate_user - that will mitigate everything that has to do with executing
user processes

mitigate_guest - same but when running guests

The third one will be the SMT off: mitigate_cross_thread.

Oh and whatever we do now, we can always change it later but that means an
additional change.

Anyway, this should be the gist of our bikeshedding.

Thoughts? Ideas?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette