Commit 192c0159 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'powerpc-7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux 

Pull powerpc updates for 7.0

 - Implement masked user access

 - Add bpf support for internal only per-CPU instructions and inline the
   bpf_get_smp_processor_id() and bpf_get_current_task() functions

 - Fix pSeries MSI-X allocation failure when quota is exceeded

 - Fix recursive pci_lock_rescan_remove locking in EEH event handling

 - Support tailcalls with subprogs & BPF exceptions on 64bit

 - Extend "trusted" keys to support the PowerVM Key Wrapping Module
   (PKWM)

Thanks to Abhishek Dubey, Christophe Leroy, Gaurav Batra, Guangshuo Li,
Jarkko Sakkinen, Mahesh Salgaonkar, Mimi Zohar, Miquel Sabaté Solà, Nam
Cao, Narayana Murty N, Nayna Jain, Nilay Shroff, Puranjay Mohan, Saket
Kumar Bhaskar, Sourabh Jain, Srish Srinivasan, and Venkat Rao Bagalkote.

* tag 'powerpc-7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (27 commits)
  powerpc/pseries: plpks: export plpks_wrapping_is_supported
  docs: trusted-encryped: add PKWM as a new trust source
  keys/trusted_keys: establish PKWM as a trusted source
  pseries/plpks: add HCALLs for PowerVM Key Wrapping Module
  pseries/plpks: expose PowerVM wrapping features via the sysfs
  powerpc/pseries: move the PLPKS config inside its own sysfs directory
  pseries/plpks: fix kernel-doc comment inconsistencies
  powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()
  powerpc: kgdb: Remove OUTBUFMAX constant
  powerpc64/bpf: Additional NVR handling for bpf_throw
  powerpc64/bpf: Support exceptions
  powerpc64/bpf: Add arch_bpf_stack_walk() for BPF JIT
  powerpc64/bpf: Avoid tailcall restore from trampoline
  powerpc64/bpf: Support tailcalls with subprogs
  powerpc64/bpf: Moving tail_call_cnt to bottom of frame
  powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling
  powerpc/pseries: Fix MSI-X allocation failure when quota is exceeded
  powerpc/iommu: bypass DMA APIs for coherent allocations for pre-mapped memory
  powerpc64/bpf: Inline bpf_get_smp_processor_id() and bpf_get_current_task/_btf()
  powerpc64/bpf: Support internal-only MOV instruction to resolve per-CPU addrs
  ...
parents 8ad8d24d e2071f9c

Documentation/ABI/testing/sysfs-firmware-plpks

0 → 100644
+58 −0
Original line number Diff line number Diff line 
What:		/sys/firmware/plpks/config

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	This optional directory contains read-only config attributes as

		defined by the PLPKS implementation. All data is in ASCII

		format.



What:		/sys/firmware/plpks/config/version

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Config version as reported by the hypervisor in ASCII decimal

		format.



What:		/sys/firmware/plpks/config/max_object_size

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Maximum allowed size of	objects in the keystore in bytes,

		represented in ASCII decimal format.



		This is not necessarily the same as the max size that can be

		written to an update file as writes can contain more than

		object data, you should use the size of the update file for

		that purpose.



What:		/sys/firmware/plpks/config/total_size

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Total size of the PLPKS in bytes, represented in ASCII decimal

		format.



What:		/sys/firmware/plpks/config/used_space

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Current space consumed by the key store, in bytes, represented

		in ASCII decimal format.



What:		/sys/firmware/plpks/config/supported_policies

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Bitmask of supported policy flags by the hypervisor, represented

		as an 8 byte hexadecimal ASCII string. Consult the hypervisor

		documentation for what these flags are.



What:		/sys/firmware/plpks/config/signed_update_algorithms

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Bitmask of flags indicating which algorithms the hypervisor

		supports for signed update of objects, represented as a 16 byte

		hexadecimal ASCII string. Consult the hypervisor documentation

		for what these flags mean.



What:		/sys/firmware/plpks/config/wrapping_features

Date:		November 2025

Contact:	Srish Srinivasan <ssrish@linux.ibm.com>

Description:	Bitmask of the wrapping features indicating the wrapping

		algorithms that are supported for the H_PKS_WRAP_OBJECT requests

		, represented as a 8 byte hexadecimal ASCII string. Consult the

		hypervisor documentation for what these flags mean.

Documentation/ABI/testing/sysfs-secvar

+0 −65
Original line number Diff line number Diff line
@@ -63,68 +63,3 @@ Contact: Nayna Jain <nayna@linux.ibm.com> 
Description:	A write-only file that is used to submit the new value for the

		variable. The size of the file represents the maximum size of

		the variable data that can be written.
 


What:		/sys/firmware/secvar/config

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	This optional directory contains read-only config attributes as

		defined by the secure variable implementation.  All data is in

		ASCII format. The directory is only created if the backing

		implementation provides variables to populate it, which at

		present is only PLPKS on the pseries platform.



What:		/sys/firmware/secvar/config/version

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Config version as reported by the hypervisor in ASCII decimal

		format.



		Currently only provided by PLPKS on the pseries platform.



What:		/sys/firmware/secvar/config/max_object_size

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Maximum allowed size of	objects in the keystore in bytes,

		represented in ASCII decimal format.



		This is not necessarily the same as the max size that can be

		written to an update file as writes can contain more than

		object data, you should use the size of the update file for

		that purpose.



		Currently only provided by PLPKS on the pseries platform.



What:		/sys/firmware/secvar/config/total_size

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Total size of the PLPKS in bytes, represented in ASCII decimal

		format.



		Currently only provided by PLPKS on the pseries platform.



What:		/sys/firmware/secvar/config/used_space

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Current space consumed by the key store, in bytes, represented

		in ASCII decimal format.



		Currently only provided by PLPKS on the pseries platform.



What:		/sys/firmware/secvar/config/supported_policies

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Bitmask of supported policy flags by the hypervisor,

		represented as an 8 byte hexadecimal ASCII string. Consult the

		hypervisor documentation for what these flags are.



		Currently only provided by PLPKS on the pseries platform.



What:		/sys/firmware/secvar/config/signed_update_algorithms

Date:		February 2023

Contact:	Nayna Jain <nayna@linux.ibm.com>

Description:	Bitmask of flags indicating which algorithms the hypervisor

		supports for signed update of objects, represented as a 16 byte

		hexadecimal ASCII string. Consult the hypervisor documentation

		for what these flags mean.



		Currently only provided by PLPKS on the pseries platform.

Documentation/admin-guide/kernel-parameters.txt

+1 −0
Original line number Diff line number Diff line
@@ -7794,6 +7794,7 @@ Kernel parameters 
			- "tee"

			- "caam"

			- "dcp"

			- "pkwm"

			If not specified then it defaults to iterating through

			the trust source list starting with TPM and assigns the

			first trust source as a backend which is initialized

Documentation/arch/powerpc/papr_hcalls.rst

+43 −0
Original line number Diff line number Diff line
@@ -300,6 +300,49 @@ H_HTM supports setup, configuration, control and dumping of Hardware Trace 
Macro (HTM) function and its data. HTM buffer stores tracing data for functions

like core instruction, core LLAT and nest.



**H_PKS_GEN_KEY**



| Input: authorization, objectlabel, objectlabellen, policy, out, outlen

| Out: *Hypervisor Generated Key, or None when the wrapping key policy is set*

| Return Value: *H_SUCCESS, H_Function, H_State, H_R_State, H_Parameter, H_P2,

                H_P3, H_P4, H_P5, H_P6, H_Authority, H_Nomem, H_Busy, H_Resource,

                H_Aborted*



H_PKS_GEN_KEY is used to have the hypervisor generate a new random key.

This key is stored as an object in the Power LPAR Platform KeyStore with

the provided object label. With the wrapping key policy set the key is only

visible to the hypervisor, while the key's label would still be visible to

the user. Generation of wrapping keys is supported only for a key size of

32 bytes.



**H_PKS_WRAP_OBJECT**



| Input: authorization, wrapkeylabel, wrapkeylabellen, objectwrapflags, in,

|        inlen, out, outlen, continue-token

| Out: *continue-token, byte size of wrapped object, wrapped object*

| Return Value: *H_SUCCESS, H_Function, H_State, H_R_State, H_Parameter, H_P2,

                H_P3, H_P4, H_P5, H_P6, H_P7, H_P8, H_P9, H_Authority, H_Invalid_Key,

                H_NOT_FOUND, H_Busy, H_LongBusy, H_Aborted*



H_PKS_WRAP_OBJECT is used to wrap an object using a wrapping key stored in the

Power LPAR Platform KeyStore and return the wrapped object to the caller. The

caller provides a label to a wrapping key with the 'wrapping key' policy set,

which must have been previously created with H_PKS_GEN_KEY. The provided object

is then encrypted with the wrapping key and additional metadata and the result

is returned to the caller.





**H_PKS_UNWRAP_OBJECT**



| Input: authorization, objectwrapflags, in, inlen, out, outlen, continue-token

| Out: *continue-token, byte size of unwrapped object, unwrapped object*

| Return Value: *H_SUCCESS, H_Function, H_State, H_R_State, H_Parameter, H_P2,

                H_P3, H_P4, H_P5, H_P6, H_P7, H_Authority, H_Unsupported, H_Bad_Data,

                H_NOT_FOUND, H_Invalid_Key, H_Busy, H_LongBusy, H_Aborted*



H_PKS_UNWRAP_OBJECT is used to unwrap an object that was previously warapped with

H_PKS_WRAP_OBJECT.



References

==========

.. [1] "Power Architecture Platform Reference"

Documentation/security/keys/trusted-encrypted.rst

+50 −0
Original line number Diff line number Diff line
@@ -81,6 +81,14 @@ safe. 
         and the UNIQUE key. Default is to use the UNIQUE key, but selecting

         the OTP key can be done via a module parameter (dcp_use_otp_key).



     (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)



         Rooted to a unique, per-LPAR key, which is derived from a system-wide,

         randomly generated LPAR root key. Both the per-LPAR keys and the LPAR

         root key are stored in hypervisor-owned secure memory at runtime,

         and the LPAR root key is additionally persisted in secure locations

         such as the processor SEEPROMs and encrypted NVRAM.



  *  Execution isolation



     (1) TPM
@@ -102,6 +110,14 @@ safe. 
         environment. Only basic blob key encryption is executed there.

         The actual key sealing/unsealing is done on main processor/kernel space.



     (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)



         Fixed set of cryptographic operations done on on-chip hardware

         cryptographic acceleration unit NX. Keys for wrapping and unwrapping

         are managed by PowerVM Platform KeyStore, which stores keys in an

         isolated in-memory copy in secure hypervisor memory, as well as in a

         persistent copy in hypervisor-encrypted NVRAM.



  * Optional binding to platform integrity state



     (1) TPM
@@ -129,6 +145,11 @@ safe. 
         Relies on Secure/Trusted boot process (called HAB by vendor) for

         platform integrity.



     (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)



         Relies on secure and trusted boot process of IBM Power systems for

         platform integrity.



  *  Interfaces and APIs



     (1) TPM
@@ -149,6 +170,11 @@ safe. 
         Vendor-specific API that is implemented as part of the DCP crypto driver in

         ``drivers/crypto/mxs-dcp.c``.



     (5) PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)



         Platform Keystore has well documented interfaces in PAPR document.

         Refer to ``Documentation/arch/powerpc/papr_hcalls.rst``



  *  Threat model



     The strength and appropriateness of a particular trust source for a given
@@ -191,6 +217,10 @@ selected trust source: 
     a dedicated hardware RNG that is independent from DCP which can be enabled

     to back the kernel RNG.



   * PKWM (PowerVM Key Wrapping Module: IBM PowerVM + Platform KeyStore)



     The normal kernel random number generator is used to generate keys.



Users may override this by specifying ``trusted.rng=kernel`` on the kernel

command-line to override the used RNG with the kernel's random number pool.
@@ -321,6 +351,26 @@ Usage:: 
specific to this DCP key-blob implementation.  The key length for new keys is

always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).



Trusted Keys usage: PKWM

------------------------



Usage::



    keyctl add trusted name "new keylen [options]" ring

    keyctl add trusted name "load hex_blob" ring

    keyctl print keyid



    options:

       wrap_flags=   ascii hex value of security policy requirement

                       0x00: no secure boot requirement (default)

                       0x01: require secure boot to be in either audit or

                             enforced mode

                       0x02: require secure boot to be in enforced mode



"keyctl print" returns an ASCII hex copy of the sealed key, which is in format

specific to PKWM key-blob implementation.  The key length for new keys is

always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).



Encrypted Keys usage

--------------------