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

Tim Gardner tim.gardner at canonical.com
Tue Jun 21 14:15:47 UTC 2022


On 6/21/22 04:36, frank.heimes at canonical.com wrote:
> BugLink: https://bugs.launchpad.net/bugs/1959973
> 
> SRU Justification:
> 
> [Impact]
> 
>   * 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.
> 
> [Fix]
> 
>   * 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
>     functionality/interface.
> 
>   * 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
> 
Acked-by: Tim Gardner <tim.gardner at canonical.com>

-- 
-----------
Tim Gardner
Canonical, Inc



More information about the kernel-team mailing list