[SRU][J][PATCH 0/3] KVM: Attestation support for Secure Execution (crypto) (LP: 1959973)

frank.heimes at canonical.com frank.heimes at canonical.com
Tue Jun 21 10:36:41 UTC 2022

BugLink: https://bugs.launchpad.net/bugs/1959973

SRU Justification:


 * This is a hardware enablement SRU in support of
   IBM z15 and LinuxONE III (FC 115) secure execution feature.

 * It adds a misc character device to expose some Ultravisor
   functions to userspace.

 * The device is only available if the (optional) Ultravisor
   Facility (158) is present in the system.

 * Two Ultravisor calls are supported:
   - Query Ultravisor Information (QUI) and
   - Receive Attestation Measurement (Attest[ation])

 * This is in support of for example. external frameworks,
   specific deployment models or especially
   potentially regulatory requirements.


 * 4689752c79fa 4689752c79fa30e91b49b39a9fba93c4d1f3e20c "drivers/s390/char: Add Ultravisor io device"

 * eb3de2d8f78d eb3de2d8f78d893303891d879f941c47f2f2d13d "s390/uv_uapi: depend on CONFIG_S390"

 * patch to set kernel config option 'CONFIG_S390_UV_UAPI=y'

[Test Plan]

 * An IBM z15 or LinuxONE III LPAR with FC 115 enabled is required.

 * Installation of Ubuntu Server 22.04 LTS on top.

 * Install a kernel that incl. the above patches/commits
   (that has the kernel config option 'CONFIG_S390_UV_UAPI' enabled).

 * Activate the kernel (reboot) and look for the existence of
   the uvdevice '/dev/uv'.

 * Use a userspace test program that makes use of the new
   misc device by exploiting 'ATTEST'.

 * Due to hardware requirements this test needs to be conducted by IBM.

[Where problems could occur]

 * The definitions in uv_cmds_inst and uv_feat_ind could be wrong
   and the codes wrong or mixed up, which would lead to a broken

 * The uvdevice header definitions could be erroneous,
   defining an wrong interface.

 * The newly added kernel options could be implemented in a wrong way,
   so that it doesn't enable the 'uvdevice', but unlikely.

 * The implementation of the device itself in 'uvdevice.c' could be broken
   by wrong or broken pointer arithmetics, wrong method arguments,
   wrong sizeof/length calculations, which - in worst case - could entirely
   crash a system.

 * The ioctl control block implementation could be wrong in a way,
   that it doesn't properly handle the case where the facility is not
   available in the system.

 * Entry point, copy and check routines could be wrong,
   allowing non-desired calls.

 * This is an s390x-only functionality,
   that is only  available on IBM z15 / LinuxONE III systems and newer,
   and only is the optional feature 'FC 115' in place,
   which is limited to 'secure-execution' workloads.

[Other Info]
 * The above commit is marked to be merged into 5.19-rc2,
   and since the planned target kernel for kinetic is
   5.19, the SRU is not needed for kinetic.

Frank Heimes (1):
  UBUNTU: [Config] CONFIG_S390_UV_UAPI=y for s390x

Paolo Bonzini (1):
  s390/uv_uapi: depend on CONFIG_S390

Steffen Eiden (1):
  drivers/s390/char: Add Ultravisor io device

 MAINTAINERS                               |   2 +
 arch/s390/include/asm/uv.h                |  23 +-
 arch/s390/include/uapi/asm/uvdevice.h     |  51 +++++
 debian.master/config/annotations          |   2 +
 debian.master/config/config.common.ubuntu |   1 +
 drivers/s390/char/Kconfig                 |  11 +
 drivers/s390/char/Makefile                |   1 +
 drivers/s390/char/uvdevice.c              | 257 ++++++++++++++++++++++
 8 files changed, 347 insertions(+), 1 deletion(-)
 create mode 100644 arch/s390/include/uapi/asm/uvdevice.h
 create mode 100644 drivers/s390/char/uvdevice.c


More information about the kernel-team mailing list