[Bug 2028936] Update Released

Tue Jan 23 22:19:49 UTC 2024

The verification of the Stable Release Update for s390-tools has
completed successfully and the package is now being released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to s390-tools-signed in Ubuntu.
https://bugs.launchpad.net/bugs/2028936

Title:
  [SEC2340] zkey: support for key type PKEY_TYPE_EP11_AES (s390-tools)

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in s390-tools package in Ubuntu:
  Fix Released
Status in s390-tools-signed package in Ubuntu:
  Fix Released
Status in s390-tools source package in Mantic:
  Fix Released
Status in s390-tools-signed source package in Mantic:
  Fix Released
Status in s390-tools source package in Noble:
  Fix Released
Status in s390-tools-signed source package in Noble:
  Fix Released

Bug description:
  SRU Justification:
  ==================

  [ Impact ]

   * The EP11 key type PKEY_TYPE_EP11 supported by zkey is incompatible with
     session bound keys.

   * In particular such keys generated in a secure guest (which are implicitly
     bound to a supervisor session) cannot be used.

   * Therefore zkey needs to be extended to support ep11 keys of the type
     PKEY_TYPE_EP11_AES.

  [Fix]

   * 1b044b8 1b044b8a40ab59e4f5ffe66e3ad81499b0beccce "zkey: Support
  EP11 AES keys with prepended header to retain EP11 session"

  [ Test Plan ]

   * An Ubuntu Server 23.10 installation with access to a CryptoExpress
     adapter in EP11 mode (CEX7P or later) is required.

   * Generate an AES key with zkey using key type EP11-AES:
     # zkey generate --name test1 --key-type EP11-AES --apqns <EP11-APQN(s)>

   * Have a look at the hex dump of the generated key:
     # xxd /etc/zkey/repository/test1.skey
     00000000: 0000 0100 0300 0100 0000 0000 0000 0000 ................
     00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
     00000020: ef92 899e be57 291e c8e8 716d 850e e2f7 .....W)...qm....
     00000030: 0000 0000 0020 8d26 0000 0000 0000 0001 ..... .&........
     00000040: 1234 d2ae cfff aa9d 15cd d2ad 9a7b 082b .4...........{.+
     ....
     The first 16 bytes are a header indicating the type of the key.
     Above example is a version 3 key (see offset 4).
     This is what you get WITHOUT the fixes.

   * A key generated with the fixes present would look like this:
     # xxd /etc/zkey/repository/test1.skey
     00000000: 0000 0110 0600 0100 0000 0000 0000 0000 ................
     00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
     00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
     00000030: ef92 899e be57 291e c8e8 716d 850e e2f7 .....W)...qm....
     00000040: 0000 0000 0020 8d26 0000 0000 0000 0001 ..... .&........
     00000050: 1234 c393 b33e fcdd 1c8f ecb6 3230 186d .4...>......20.m
     ...
     Here, its a version 6 key (see offset 4, PKEY_TYPE_EP11_AES = 6).
     With the fixes present, you should always get version 6 keys.
     So if you see a version 6 key, then the fix is present and working.

   * FWIW: The 32 bytes following the 16 bytes header are the
     session ID of the key.
     Unless you are in a secure execution environment they are zero.
     If you are in a secure execution environment they would be non-zero.
     For a version 3 key, the session ID would be the very first 32 bytes,
     but it is overlayed (and thus destroyed) by the 16 bytes header
     information.
     So version 3 keys can not be session bound, but version 6 keys can be
     session bound.
     Thus, only version 6 keys can be used in a secure execution environment.

   * To test if the key is usable, run a validate command:
     # zkey validate --name test1

   * Furthermore, setup a dm-crypt volume using such a version 6 key
     by following the steps described here:
     https://www.ibm.com/docs/en/linux-on-systems?topic=volumes-creating-volume-pervasive-encryption

   * If you can successfully open that dm-crypt volume then it ensures that
     also the pkey/paes_s390 kernel modules contains the required fixes
     and can work with such a key.

   * Like suggested/requested in comment #10 a regression testing would make
     sense and could be best done based on the pkey kernel module modifications.
     And with that the libzpc tests (directly from upstream) are a good option:
     https://github.com/opencryptoki/libzpc#Testing
     libzpc's runtest runs by default 140 tests from 13 test suites and allows
     to explicitly enable EC test in combination with EP11 using the env. var.:
     ZPC_TEST_EC_KEY_TYPE=ZPC_EC_KEY_TYPE_EP11:
     ~$ git clone https://github.com/opencryptoki/libzpc
     ~$ sudo apt install libjson-c-dev cmake
     ~$ cd libzpc/
     ~/libzpc$ mkdir build && cd build
     ~/libzpc/build$ cmake -DBUILD_TEST=ON ..
     [ in case a proxy is required:
       $ export https_proxy="http://your.proxy:3128/" ]
     ~/libzpc/build$ make
     ~/libzpc/build$ ./runtest
     Check from the output if the "ec"* tests are marked as "PASSED"

  [ Where problems could occur ]

   * A parameter in select_ep11_apqn_by_mkvp struct was changed and renamed,
     in case the renaming is not overarching, the code will break.
     This can be checked by a test build.

   * In case the content of the ep11key_blob is not decomposed properly,
     the two different types PKEY_TYPE_EP11 and PKEY_TYPE_EP11_AES
     might be mixed up, which will break pkey handling.

   * If the sizeof calculation of the headers is wrong, a wrong
     header/PKEY_TYPE might be assumed.

   * The setup of the new EP11 token header was redone. In case of issues
     here the EP11 token header might be wrong, hence later not properly
     detected and/or unusable.

   * Code was added to check if the pkey module supports keys of type
     TOKEN_VERSION_EP11_AES_WITH_HEADER, since older kernels may not support
     such keys.
     This can be faulty, which may lead to wrong assumptions about the support.
     Or the conversion to TOKEN_VERSION_EP11_AES type can be erroneous.

   * Similar for gensek2 and clr2seck2.

   * Checks if key is EP11 AES key token with external header and
     EP11 AES key is session bound may again lead to wrong assumptions
     in case of issues.

   * Fortunately all this is s390x specific,
     and does not affect a default installation,
     but mainly confidential computing environments (aka secure execution).

  [ Other Info ]

   * The commit/patch is upstream since Aug 21st 2023.
  __________

  The EP11 key type PKEY_TYPE_EP11 supported by zkey is incompatible with session bound keys. In particular such keys generated in a secure guest (which are implicitly bound to a supervisor session) cannot be used.
  Therefore zkey needs to be extended to support ep11 keys of the type PKEY_TYPE_EP11_AES.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2028936/+subscriptions