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
| ||
|
Date: Fri, 28 Jan 2022 15:10:16 -0800 From: Ira Weiny <ira.weiny@...el.com> To: Dave Hansen <dave.hansen@...el.com> Cc: Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, Dan Williams <dan.j.williams@...el.com>, Fenghua Yu <fenghua.yu@...el.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH V8 06/44] mm/pkeys: Add Kconfig options for PKS On Fri, Jan 28, 2022 at 02:54:26PM -0800, Dave Hansen wrote: > On 1/27/22 09:54, ira.weiny@...el.com wrote: > > From: Ira Weiny <ira.weiny@...el.com> > > > > Protection Key Supervisor, PKS, is a feature used by kernel code only. > > As such if no kernel users are configured the PKS code is unnecessary > > overhead. Indeed this was a bit weak sorry. See below. > > > > Define a Kconfig structure which allows kernel code to detect PKS > > support by an architecture and then subsequently enable that support > > within the architecture. > > > > ARCH_HAS_SUPERVISOR_PKEYS indicates to kernel consumers that an > > architecture supports pkeys. PKS users can then select > > ARCH_ENABLE_SUPERVISOR_PKEYS to turn on the support within the > > architecture. > > > > If ARCH_ENABLE_SUPERVISOR_PKEYS is not selected architectures avoid the > > PKS overhead. > > > > ARCH_ENABLE_SUPERVISOR_PKEYS remains off until the first kernel use case > > sets it. > > This is heavy on the "what" and weak on the "why". > > Why isn't this an x86-specific Kconfig? Why do we need two Kconfigs? > Good old user pkeys only has one: > > config ARCH_HAS_PKEYS > bool > > and it's in arch-generic code because there are ppc and x86 > implementations *and* the pkey support touches generic code. > > This might become evident later in the series, but it's clear as mud as > it stands. Sorry, I'll expand on this. This issue is that because PKS users are in kernel only and are not part of the architecture specific code there needs to be 2 mechanisms within the Kconfig structure. One to communicate an architectures support PKS such that the user who needs it can depend on that config as well as a second to allow that user to communicate back to the architecture to enable PKS. Ira
Powered by blists - more mailing lists