linux-kernel - Re: [PATCH v4 1/3] arch/x86: Update config and kernel doc for MPK feature on AMD

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]

Date:   Wed, 13 May 2020 08:09:41 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Babu Moger <babu.moger@....com>, corbet@....net,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
        pbonzini@...hat.com, sean.j.christopherson@...el.com
Cc:     x86@...nel.org, vkuznets@...hat.com, wanpengli@...cent.com,
        jmattson@...gle.com, joro@...tes.org, dave.hansen@...ux.intel.com,
        luto@...nel.org, peterz@...radead.org, mchehab+samsung@...nel.org,
        changbin.du@...el.com, namit@...are.com, bigeasy@...utronix.de,
        yang.shi@...ux.alibaba.com, asteinhauser@...gle.com,
        anshuman.khandual@....com, jan.kiszka@...mens.com,
        akpm@...ux-foundation.org, steven.price@....com,
        rppt@...ux.vnet.ibm.com, peterx@...hat.com,
        dan.j.williams@...el.com, arjunroy@...gle.com, logang@...tatee.com,
        thellstrom@...are.com, aarcange@...hat.com, justin.he@....com,
        robin.murphy@....com, ira.weiny@...el.com, keescook@...omium.org,
        jgross@...e.com, andrew.cooper3@...rix.com,
        pawan.kumar.gupta@...ux.intel.com, fenghua.yu@...el.com,
        vineela.tummalapalli@...el.com, yamada.masahiro@...ionext.com,
        sam@...nborg.org, acme@...hat.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v4 1/3] arch/x86: Update config and kernel doc for MPK
 feature on AMD

On 5/12/20 4:58 PM, Babu Moger wrote:
> +config X86_MEMORY_PROTECTION_KEYS
> +	# Both Intel and AMD platforms support "Memory Protection Keys"
> +	# feature. So add a generic option X86_MEMORY_PROTECTION_KEYS
> +	# and set the option whenever X86_INTEL_MEMORY_PROTECTION_KEYS
> +	# is set. This is to avoid the confusion about the feature
> +	# availability on AMD platforms. Also renaming the old option
> +	# would cause the user an extra prompt during the kernel
> +	# configuration. So avoided changing the old config name.
> +	def_bool X86_INTEL_MEMORY_PROTECTION_KEYS

Hi Babu,

I made a request earlier for an end date (or version) to be included
here.  I believe that appeared in one of your earlier versions, but it
was removed in later ones.

Was there a reason for that?

I'd really prefer to put some kind of expiration date on the config
option.  It will outlive us all otherwise.

>  Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature
>  which is found on Intel's Skylake "Scalable Processor" Server CPUs.
> -It will be avalable in future non-server parts.
> +It will be available in future non-server parts. Also, AMD64
> +Architecture Programmer’s Manual defines PKU feature in AMD processors.

I actually worked pretty hard to make that sentence useful to Linux
users.  Instead of forcing them to imply that it will be available on
future AMD CPUs, can we just come out and say it?  Can we give any more
information to our users?

Naming the AMD manual in which the feature is defined doesn't really
help our users.  Let's not waste the bytes on it.

How about:

	Memory Protection Keys for Userspace (PKU aka PKEYs) is a
	feature which is found on Intel's Skylake (and later) "Scalable
	Processor" Server CPUs.  It will be avalable in future non-
	server Intel parts and future AMD parts.

Any clarity you can add, such as to say what AMD is doing for server vs.
client  would be nice.

BTW, when I first submitted pkeys, I didn't have any statement like this
in the changelog or documentation.  Ingo, I think, asked for it and I
worked with folks inside Intel to figure out how much we could say
publicly about our plans.  A similar effort from AMD would be much
appreciated here.