linux-kernel - Re: [PATCH V8 06/44] mm/pkeys: Add Kconfig options for PKS

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: <20220214230350.GW785175@iweiny-DESK2.sc.intel.com>
Date:   Mon, 14 Feb 2022 15:03:50 -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 Mon, Feb 14, 2022 at 11:20:20AM -0800, Dave Hansen wrote:
> On 2/8/22 21:34, Ira Weiny wrote:
> >>> In other words, there are two things that must happen before the code
> >>> gets compiled in:
> >>>
> >>> 1. Arch support
> >>> 2. One or more features to use the arch support
> >> Yes.  I really think we are both say the same thing with different words.
> > Is the following more clear?
> > 
> > <commit>
> > 
> > PKS is only useful to kernel consumers and is only available on some
> > architectures.  If no kernel consumers are configured or PKS support is
> > not available the PKS code can be eliminated from the compile.
> > 
> > Define a Kconfig structure which allows kernel consumers to detect
> > architecture support (ARCH_HAS_SUPERVISOR_PKEYS) and, if available,
> > indicate that PKS should be compiled in (ARCH_ENABLE_SUPERVISOR_PKEYS).
> > 
> > In this patch ARCH_ENABLE_SUPERVISOR_PKEYS remains off until the first
> > kernel consumer sets it.
> 
> It's a bit more clear.  I wish it was more clear about the problem.  I
> think it would be well-served to add some specifics and clarify the
> *problem*.  Maybe something like:

;-(  Ok.

> 
> == Problem ==
> 
> PKS support is provided by core x86 architecture code.  Its consumers,
> however, may be far-flung device drivers like NVDIMM support.  The PKS
> core architecture code is dead weight without a consumer.

This is not the whole story though.  The far-flung device drivers don't need to
compile their PKS code, or may not be able to support a feature, if
ARCH_HAS_SUPERVISOR_PKEYS is not set.  Also, they may wish to chose a different
implementation for the same functionality if available.  So
ARCH_HAS_SUPERVISOR_PKEYS can affect more than just if PKS code is compiled.
It could affect how drivers chose to implement some higher level feature.

> 
> --- maybe add one example ---
> 
> == Solution ==
> 
> Avoid even compiling in the core PKS code if there are no consumers.

And allow users to avoid compiling PKS code on architectures which
don't support PKS.  Or chose another implementation if possible.

I'll try again.

<msg>

Consumers wishing to implement additional protections on memory pages may be
able to use PKS.  However, PKS is only available on some architectures.

In addition, PKS code, both in the core and in these consumers would be dead
code without PKS being both available and used.  Therefore, if no kernel
consumers are configured or PKS support is not available all the PKS code can
be eliminated from the compile.

Avoid using PKS if the architecture does not support it.  Furthermore,
avoid compiling any PKS code if their are no consumers configured to use 
it.

Define ARCH_HAS_SUPERVISOR_PKEYS to detect architecture support and
define ARCH_ENABLE_SUPERVISOR_PKEYS to indicate the core should compile
in support.

In this patch ARCH_ENABLE_SUPERVISOR_PKEYS remains off until the first
kernel consumer sets it.

</msg>

Ira

> 
> == Details ==