| 2023-07-28 11:49:24 |
bugproxy |
bug |
|
|
added bug |
| 2023-07-28 11:49:26 |
bugproxy |
tags |
|
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2310 |
|
| 2023-07-28 11:49:27 |
bugproxy |
ubuntu: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2023-07-28 11:49:29 |
bugproxy |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2023-07-28 11:49:30 |
bugproxy |
bug |
|
|
added subscriber CDE Administration |
| 2023-07-28 11:49:31 |
bugproxy |
bug |
|
|
added subscriber Boris Barth |
| 2023-07-28 12:26:50 |
Frank Heimes |
affects |
linux (Ubuntu) |
s390-tools (Ubuntu) |
|
| 2023-07-28 12:27:00 |
Frank Heimes |
bug task added |
|
ubuntu-z-systems |
|
| 2023-07-28 12:27:07 |
Frank Heimes |
s390-tools (Ubuntu): importance |
Undecided |
High |
|
| 2023-07-28 12:27:10 |
Frank Heimes |
ubuntu-z-systems: importance |
Undecided |
Medium |
|
| 2023-07-28 12:27:12 |
Frank Heimes |
ubuntu-z-systems: status |
New |
Incomplete |
|
| 2023-07-28 12:27:13 |
Frank Heimes |
s390-tools (Ubuntu): status |
New |
Incomplete |
|
| 2023-07-28 12:27:26 |
Frank Heimes |
ubuntu-z-systems: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2023-07-28 12:27:30 |
Frank Heimes |
s390-tools (Ubuntu): assignee |
Skipper Bug Screeners (skipper-screen-team) |
|
|
| 2023-08-16 15:59:30 |
bugproxy |
tags |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2310 |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 |
|
| 2023-08-17 11:21:24 |
Frank Heimes |
summary |
[23.10 FEAT] [SEC2340] zkey: support for key type PKEY_TYPE_EP11_AES (s390-tools) |
[24.04 FEAT] [SEC2340] zkey: support for key type PKEY_TYPE_EP11_AES (s390-tools) |
|
| 2023-08-30 16:40:37 |
Frank Heimes |
ubuntu-z-systems: status |
Incomplete |
Triaged |
|
| 2023-08-30 16:40:41 |
Frank Heimes |
s390-tools (Ubuntu): status |
Incomplete |
Triaged |
|
| 2023-11-28 13:20:25 |
Frank Heimes |
bug task added |
|
s390-tools-signed (Ubuntu) |
|
| 2023-11-28 13:20:34 |
Frank Heimes |
s390-tools-signed (Ubuntu): status |
New |
Triaged |
|
| 2023-11-28 13:20:37 |
Frank Heimes |
s390-tools-signed (Ubuntu): importance |
Undecided |
High |
|
| 2023-11-28 14:16:36 |
Frank Heimes |
description |
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. |
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 ]
* <detailed instructions how to reproduce the bug>
* <these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.>
* <if other testing is appropriate to perform before landing this update,
this should also be described here.>
[ 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. |
|
| 2023-11-29 09:10:57 |
Frank Heimes |
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 ]
* <detailed instructions how to reproduce the bug>
* <these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.>
* <if other testing is appropriate to perform before landing this update,
this should also be described here.>
[ 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. |
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.
[ 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. |
|
| 2023-11-29 09:16:28 |
Frank Heimes |
information type |
Private |
Public |
|
| 2023-11-29 09:26:52 |
Frank Heimes |
attachment added |
|
debdiffs.tgz https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/2028936/+attachment/5724634/+files/debdiffs.tgz |
|
| 2023-11-29 09:28:27 |
Frank Heimes |
bug |
|
|
added subscriber Ubuntu Sponsors |
| 2023-11-29 17:12:43 |
Simon Chopin |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2023-11-29 17:12:48 |
Simon Chopin |
s390-tools (Ubuntu): assignee |
|
Simon Chopin (schopin) |
|
| 2023-11-29 17:12:51 |
Simon Chopin |
s390-tools-signed (Ubuntu): assignee |
|
Simon Chopin (schopin) |
|
| 2023-12-06 15:11:21 |
Simon Chopin |
s390-tools (Ubuntu): assignee |
Simon Chopin (schopin) |
|
|
| 2023-12-06 15:11:23 |
Simon Chopin |
s390-tools-signed (Ubuntu): assignee |
Simon Chopin (schopin) |
|
|
| 2023-12-06 15:11:29 |
Simon Chopin |
nominated for series |
|
Ubuntu Noble |
|
| 2023-12-06 15:11:29 |
Simon Chopin |
bug task added |
|
s390-tools (Ubuntu Noble) |
|
| 2023-12-06 15:11:29 |
Simon Chopin |
bug task added |
|
s390-tools-signed (Ubuntu Noble) |
|
| 2023-12-06 15:11:29 |
Simon Chopin |
nominated for series |
|
Ubuntu Mantic |
|
| 2023-12-06 15:11:29 |
Simon Chopin |
bug task added |
|
s390-tools (Ubuntu Mantic) |
|
| 2023-12-06 15:11:29 |
Simon Chopin |
bug task added |
|
s390-tools-signed (Ubuntu Mantic) |
|
| 2023-12-06 15:12:18 |
Simon Chopin |
s390-tools (Ubuntu Noble): status |
Triaged |
Fix Committed |
|
| 2023-12-06 15:12:21 |
Simon Chopin |
s390-tools-signed (Ubuntu Noble): status |
Triaged |
Fix Committed |
|
| 2023-12-06 15:27:29 |
Frank Heimes |
ubuntu-z-systems: status |
Triaged |
Fix Committed |
|
| 2023-12-06 15:43:49 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Simon Chopin |
| 2023-12-08 23:21:58 |
Steve Langasek |
s390-tools (Ubuntu Noble): status |
Fix Committed |
Incomplete |
|
| 2023-12-14 13:00:44 |
Frank Heimes |
s390-tools (Ubuntu Noble): status |
Incomplete |
In Progress |
|
| 2023-12-14 21:10:53 |
Frank Heimes |
s390-tools (Ubuntu Noble): status |
In Progress |
Incomplete |
|
| 2023-12-14 21:10:59 |
Frank Heimes |
ubuntu-z-systems: status |
Fix Committed |
In Progress |
|
| 2023-12-27 14:19:40 |
bugproxy |
bug watch added |
|
https://bugzilla.linux.ibm.com/show_bug.cgi?id=203279 |
|
| 2024-01-03 10:24:07 |
Frank Heimes |
summary |
[24.04 FEAT] [SEC2340] zkey: support for key type PKEY_TYPE_EP11_AES (s390-tools) |
[SEC2340] zkey: support for key type PKEY_TYPE_EP11_AES (s390-tools) |
|
| 2024-01-03 13:23:47 |
Frank Heimes |
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.
[ 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. |
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. |
|
| 2024-01-03 13:23:57 |
Frank Heimes |
s390-tools (Ubuntu Noble): status |
Incomplete |
New |
|
| 2024-01-04 22:48:37 |
Launchpad Janitor |
s390-tools-signed (Ubuntu Noble): status |
Fix Committed |
Fix Released |
|
| 2024-01-04 23:14:22 |
Launchpad Janitor |
s390-tools (Ubuntu Noble): status |
New |
Fix Released |
|
| 2024-01-05 20:10:05 |
Steve Langasek |
s390-tools (Ubuntu Mantic): status |
New |
Fix Committed |
|
| 2024-01-05 20:10:07 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-01-05 20:10:12 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2024-01-05 20:10:17 |
Steve Langasek |
tags |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 verification-needed verification-needed-mantic |
|
| 2024-01-05 20:13:19 |
Steve Langasek |
s390-tools-signed (Ubuntu Mantic): status |
New |
Fix Committed |
|
| 2024-01-06 13:56:03 |
Frank Heimes |
ubuntu-z-systems: status |
In Progress |
Fix Committed |
|
| 2024-01-08 12:49:38 |
bugproxy |
tags |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 verification-needed verification-needed-mantic |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 |
|
| 2024-01-08 15:32:07 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 verification-needed verification-needed-mantic |
|
| 2024-01-08 16:29:38 |
bugproxy |
tags |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 verification-needed verification-needed-mantic |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 |
|
| 2024-01-09 12:49:47 |
bugproxy |
tags |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 verification-done |
|
| 2024-01-23 13:25:31 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 verification-done |
architecture-s39064 bugnameltc-203280 severity-high targetmilestone-inin2404 verification-done verification-done-mantic |
|
| 2024-01-23 22:19:41 |
Launchpad Janitor |
s390-tools (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
| 2024-01-23 22:19:44 |
Launchpad Janitor |
s390-tools-signed (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
| 2024-01-23 22:19:48 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-01-24 07:41:19 |
Frank Heimes |
ubuntu-z-systems: status |
Fix Committed |
Fix Released |
|
