Comment 4 for bug 2028936

------- Comment From <email address hidden> 2023-11-29 02:59 EDT-------
A real test of this fix would require a system running in secure execution mode that has access to a CryptoExpress adapter in EP11 mode via secure AP passthrough.
There all EP11 keys are session bound, and without that fix all EP11 keys generated by zkey would simply not work, i.e. they could not be used for dm-crypt.

However, even without secure execution the effect of this fix can be checked.
You still need a system with a CryptoExpress adapter in EP11 mode (CEX7P or later).

Generate an AES key with zkey using key type EP11-AES:

# zkey generate --name test1 --key-type EP11-AES --apqns <EP11-APQN(s)>

Then 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.

FYI: 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.