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.
------- Comment From <email address hidden> 2023-08-16 11:55 EDT-------
This feature is not yet available.
With this, we are missing Mantic FF. Therefore, we need to postpone to the next Ubuntu release.
==> Changing target milestone to: "24.04"