| 2023-01-23 03:09:22 |
bugproxy |
bug |
|
|
added bug |
| 2023-01-23 03:09:25 |
bugproxy |
tags |
|
architecture-s39064 bugnameltc-201348 severity-high targetmilestone-inin2304 |
|
| 2023-01-23 03:09:26 |
bugproxy |
ubuntu: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2023-01-23 03:09:28 |
bugproxy |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2023-01-23 03:09:29 |
bugproxy |
bug |
|
|
added subscriber CDE Administration |
| 2023-01-23 03:09:31 |
bugproxy |
bug |
|
|
added subscriber Boris Barth |
| 2023-01-23 06:45:23 |
Frank Heimes |
affects |
linux (Ubuntu) |
qemu (Ubuntu) |
|
| 2023-01-23 06:45:33 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-201348 severity-high targetmilestone-inin2304 |
architecture-s39064 bugnameltc-201348 qemu-23.04 severity-high targetmilestone-inin2304 |
|
| 2023-01-23 06:45:48 |
Frank Heimes |
bug task added |
|
ubuntu-z-systems |
|
| 2023-01-23 06:46:18 |
Frank Heimes |
ubuntu-z-systems: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2023-01-23 06:46:21 |
Frank Heimes |
ubuntu-z-systems: importance |
Undecided |
High |
|
| 2023-01-23 06:46:24 |
Frank Heimes |
qemu (Ubuntu): importance |
Undecided |
High |
|
| 2023-01-23 06:46:30 |
Frank Heimes |
qemu (Ubuntu): status |
New |
Incomplete |
|
| 2023-01-23 06:46:32 |
Frank Heimes |
ubuntu-z-systems: status |
New |
Incomplete |
|
| 2023-06-14 09:52:03 |
Christian Ehrhardt |
tags |
architecture-s39064 bugnameltc-201348 qemu-23.04 severity-high targetmilestone-inin2304 |
architecture-s39064 bugnameltc-201348 qemu-23.10 severity-high targetmilestone-inin2304 |
|
| 2023-06-14 10:07:10 |
Frank Heimes |
summary |
[23.04 FEAT] KVM: Enable Secure Execution Crypto Passthrough - qemu part |
[23.10 FEAT] KVM: Enable Secure Execution Crypto Passthrough - qemu part |
|
| 2023-07-14 16:59:35 |
bugproxy |
tags |
architecture-s39064 bugnameltc-201348 qemu-23.10 severity-high targetmilestone-inin2304 |
architecture-s39064 bugnameltc-201348 qemu-23.10 severity-high targetmilestone-inin2310 |
|
| 2023-08-16 15:59:41 |
bugproxy |
tags |
architecture-s39064 bugnameltc-201348 qemu-23.10 severity-high targetmilestone-inin2310 |
architecture-s39064 bugnameltc-201348 qemu-23.10 severity-high targetmilestone-inin2404 |
|
| 2023-08-17 11:23:25 |
Frank Heimes |
summary |
[23.10 FEAT] KVM: Enable Secure Execution Crypto Passthrough - qemu part |
[24.04 FEAT] KVM: Enable Secure Execution Crypto Passthrough - qemu part |
|
| 2023-08-17 11:23:36 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-201348 qemu-23.10 severity-high targetmilestone-inin2404 |
architecture-s39064 bugnameltc-201348 qemu-24.04 severity-high targetmilestone-inin2404 |
|
| 2023-09-13 11:05:57 |
Frank Heimes |
summary |
[24.04 FEAT] KVM: Enable Secure Execution Crypto Passthrough - qemu part |
[FFe] KVM: Enable Secure Execution Crypto Passthrough - qemu part |
|
| 2023-09-13 11:06:01 |
Frank Heimes |
ubuntu-z-systems: status |
Incomplete |
New |
|
| 2023-09-13 11:06:04 |
Frank Heimes |
qemu (Ubuntu): status |
Incomplete |
New |
|
| 2023-10-10 18:05:04 |
Frank Heimes |
summary |
[FFe] KVM: Enable Secure Execution Crypto Passthrough - qemu part |
KVM: Enable Secure Execution Crypto Passthrough - qemu part |
|
| 2023-10-19 15:57:52 |
Frank Heimes |
description |
Feature Description:
Enable KVM and QEMU for AP passthrough to Secure Execution guests. This includes setup, configuration and teardown of AP related resources. |
SRU Justification:
[ Impact ]
* As of today IBM Z crypto hardware (AP, Adjunct Processor, an IBM Z cryptographic facility, that provides cryptographic virtual functions to Linux on Z system) cannot be passed-through to Secure Execution guests (pv-guests) by KVM and QEMU. (All this in context of confidential computing aka secure execution.)
* But it's highly desired to make use of APs from within Secure Execution guests, since they make significant use of cryptography in general, hence this should be ideally off-loadable and supported by hardware cryptographic (APs).
* Enabling KVM and QEMU for AP passthrough to Secure Execution guests includes setup, configuration and tear-down of AP related resources and affects Kernel, qemu (and s390-tools).
* QEMU has to turn on the corresponding bits in the KVM CPU-model if the CPU firmware supports it.
* However, it only makes sense to turn on AP-PT if the QEMU user enabled (general) AP for that guest.
* The kernel adjustments (which is the bigger set of changes with 20+ commits) made it in time for mantic into the Ubuntu kernel 6.5 (backports from 6.6), but not the qemu changes.
* This SRU seeks an exception, to add the needed qemu changes post-GA to bring this overall functionality to work, since it's desired to exploit this as part of a product.
[ Test Plan ]
* Have an Ubuntu 23.10 LPAR with at least one (better several) APs assigned. Check with:
$ lszcrypt -V
CARD.DOM TYPE MODE STATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER
--------------------------------------------------------------------------------------------
00 CEX7C CCA-Coproc online 1 0 11 08 S--D--N--- cex7card
00.000a CEX/C CCA-Coproc online 1 0 11 08 S--D--N--- cex7queue
* Setup a secure execution environment according to
'Introducing IBM Secure Execution for Linux' (SC34-7721-03)
See PDF page #15 ff, that use Ubuntu as an example.
* Pass selected AP resources from the KVM host through to the Secure Execution (SE) guest.
* Enable the SE guest to make use of hardware cryptographic facilities by installing the needed packages:
$ sudo apt-get install libica-utils libica? openssl-ibmca
and configure openssl:
$ sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf
This allows to make use of the ibmca openssl engine:
$ openssl engine -c
(dynamic) Dynamic engine loading support
(ibmca) Ibmca hardware engine support
[RSA, DSA, DH, RAND, DES-ECB, DES-CBC, DES-OFB, DES-CFB, DES-EDE3, DES-EDE3-CBC, DES-EDE3-OFB,
DES-EDE3-CFB, AES-128-ECB, AES-192-ECB, AES-256-ECB, AES-128-CBC, AES-192-CBC, AES-256-CBC,
AES-128-OFB, AES-192-OFB, AES-256-OFB, AES-128-CFB, AES-192-CFB, AES-256-CFB, SHA1, SHA256, SHA512]
* Reset the icastats crypto counters with (just in case they are not zero):
$ icastats -r
* Consume cryptographic resources in the secure guest that are known to be executed
by the underlying and passed through hardware cryptography.
For example:
$ openssl speed -evp aes-256-cbc 2>/dev/null | tail -n 3
will provide this output:
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
AES-256-CBC 160454.13k 510929.25k 1272902.21k 1590194.94k 1708914.64k 1702523.78k
and will especially lead to icastats counter entries (indicating hardware use) for DRBG-SHA-512:
$ icastats | grep DRBG-SHA-512
DRBG-SHA-512 | 175 | 0
[
Alternatively use ssh to consume hardware crypto, like with (do an 'icastats -r' before):
$ ssh -c chacha20-poly1305@openssh.com ubuntu@localhost
that will lead to these counter entries:
$ icastats | grep 'DRBG-SHA-512\|RSA-ME'
DRBG-SHA-512 | 171 | 0
RSA-ME | 1 | 0
]
* The verification needs to be done by IBM.
[ Where problems could occur ]
* Commits 297ec01f0b and ef1535901a are very small fixes (each one line),
that are pretty traceable.
* Commit da3c22c74a introduces the needed kernel 6.6 header changes.
These fit to the 23.10 kernel (since they were already cherry picked: LP#2003674)
They touch common code files and can potentially affect other architectures.
However, the majority of modification are additional definitions.
* Commits 354383c122 touches the s390x target only,
refactors AP, and changes check, test and set functions.
Hence if done errornously this can lead to a wrong states.
Or if the refactoring wasn't done complete functions might be missed,
but this of course is checked by a test build.
Overall this does not look too invasive.
* Commit 5ac951519c, again touching s390x code only,
is the actual AP-passthrough for PV guests.
It adds this feature similar to other the existing ones, and expands the CPU model.
No code is removed, but only added to existing functions and a new set of
functions got introduced: uv_feat_supported, query_uv_feat_guest, configure_uv_feat_guest
In case of issues with these, query or config of features can be harmed
which might lead to wrong states or even break the code.
[ Other Info ]
* It's for our partner IBM an important new feature (as confidential computing is in general),
which unfortunately landed late in qemu.
* It's with 5 patches (with two of them one line fixes) not very invasive.
* The modification can be and will be thoroughly tested.
__________
Feature Description:
Enable KVM and QEMU for AP passthrough to Secure Execution guests. This includes setup, configuration and teardown of AP related resources. |
|
| 2023-10-19 15:59:17 |
Frank Heimes |
description |
SRU Justification:
[ Impact ]
* As of today IBM Z crypto hardware (AP, Adjunct Processor, an IBM Z cryptographic facility, that provides cryptographic virtual functions to Linux on Z system) cannot be passed-through to Secure Execution guests (pv-guests) by KVM and QEMU. (All this in context of confidential computing aka secure execution.)
* But it's highly desired to make use of APs from within Secure Execution guests, since they make significant use of cryptography in general, hence this should be ideally off-loadable and supported by hardware cryptographic (APs).
* Enabling KVM and QEMU for AP passthrough to Secure Execution guests includes setup, configuration and tear-down of AP related resources and affects Kernel, qemu (and s390-tools).
* QEMU has to turn on the corresponding bits in the KVM CPU-model if the CPU firmware supports it.
* However, it only makes sense to turn on AP-PT if the QEMU user enabled (general) AP for that guest.
* The kernel adjustments (which is the bigger set of changes with 20+ commits) made it in time for mantic into the Ubuntu kernel 6.5 (backports from 6.6), but not the qemu changes.
* This SRU seeks an exception, to add the needed qemu changes post-GA to bring this overall functionality to work, since it's desired to exploit this as part of a product.
[ Test Plan ]
* Have an Ubuntu 23.10 LPAR with at least one (better several) APs assigned. Check with:
$ lszcrypt -V
CARD.DOM TYPE MODE STATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER
--------------------------------------------------------------------------------------------
00 CEX7C CCA-Coproc online 1 0 11 08 S--D--N--- cex7card
00.000a CEX/C CCA-Coproc online 1 0 11 08 S--D--N--- cex7queue
* Setup a secure execution environment according to
'Introducing IBM Secure Execution for Linux' (SC34-7721-03)
See PDF page #15 ff, that use Ubuntu as an example.
* Pass selected AP resources from the KVM host through to the Secure Execution (SE) guest.
* Enable the SE guest to make use of hardware cryptographic facilities by installing the needed packages:
$ sudo apt-get install libica-utils libica? openssl-ibmca
and configure openssl:
$ sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf
This allows to make use of the ibmca openssl engine:
$ openssl engine -c
(dynamic) Dynamic engine loading support
(ibmca) Ibmca hardware engine support
[RSA, DSA, DH, RAND, DES-ECB, DES-CBC, DES-OFB, DES-CFB, DES-EDE3, DES-EDE3-CBC, DES-EDE3-OFB,
DES-EDE3-CFB, AES-128-ECB, AES-192-ECB, AES-256-ECB, AES-128-CBC, AES-192-CBC, AES-256-CBC,
AES-128-OFB, AES-192-OFB, AES-256-OFB, AES-128-CFB, AES-192-CFB, AES-256-CFB, SHA1, SHA256, SHA512]
* Reset the icastats crypto counters with (just in case they are not zero):
$ icastats -r
* Consume cryptographic resources in the secure guest that are known to be executed
by the underlying and passed through hardware cryptography.
For example:
$ openssl speed -evp aes-256-cbc 2>/dev/null | tail -n 3
will provide this output:
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
AES-256-CBC 160454.13k 510929.25k 1272902.21k 1590194.94k 1708914.64k 1702523.78k
and will especially lead to icastats counter entries (indicating hardware use) for DRBG-SHA-512:
$ icastats | grep DRBG-SHA-512
DRBG-SHA-512 | 175 | 0
[
Alternatively use ssh to consume hardware crypto, like with (do an 'icastats -r' before):
$ ssh -c chacha20-poly1305@openssh.com ubuntu@localhost
that will lead to these counter entries:
$ icastats | grep 'DRBG-SHA-512\|RSA-ME'
DRBG-SHA-512 | 171 | 0
RSA-ME | 1 | 0
]
* The verification needs to be done by IBM.
[ Where problems could occur ]
* Commits 297ec01f0b and ef1535901a are very small fixes (each one line),
that are pretty traceable.
* Commit da3c22c74a introduces the needed kernel 6.6 header changes.
These fit to the 23.10 kernel (since they were already cherry picked: LP#2003674)
They touch common code files and can potentially affect other architectures.
However, the majority of modification are additional definitions.
* Commits 354383c122 touches the s390x target only,
refactors AP, and changes check, test and set functions.
Hence if done errornously this can lead to a wrong states.
Or if the refactoring wasn't done complete functions might be missed,
but this of course is checked by a test build.
Overall this does not look too invasive.
* Commit 5ac951519c, again touching s390x code only,
is the actual AP-passthrough for PV guests.
It adds this feature similar to other the existing ones, and expands the CPU model.
No code is removed, but only added to existing functions and a new set of
functions got introduced: uv_feat_supported, query_uv_feat_guest, configure_uv_feat_guest
In case of issues with these, query or config of features can be harmed
which might lead to wrong states or even break the code.
[ Other Info ]
* It's for our partner IBM an important new feature (as confidential computing is in general),
which unfortunately landed late in qemu.
* It's with 5 patches (with two of them one line fixes) not very invasive.
* The modification can be and will be thoroughly tested.
__________
Feature Description:
Enable KVM and QEMU for AP passthrough to Secure Execution guests. This includes setup, configuration and teardown of AP related resources. |
SRU Justification:
[ Impact ]
* As of today IBM Z crypto hardware (AP, Adjunct Processor, an IBM Z cryptographic facility, that provides cryptographic virtual functions to Linux on Z system) cannot be passed-through to Secure Execution guests (pv-guests) by KVM and QEMU. (All this in context of confidential computing aka secure execution.)
* But it's highly desired to make use of APs from within Secure Execution guests, since they make significant use of cryptography in general, hence this should be ideally off-loadable and supported by hardware cryptographic (APs).
* Enabling KVM and QEMU for AP passthrough to Secure Execution guests includes setup, configuration and tear-down of AP related resources and affects Kernel, qemu (and s390-tools).
* QEMU has to turn on the corresponding bits in the KVM CPU-model if the CPU firmware supports it.
* However, it only makes sense to turn on AP-PT if the QEMU user enabled (general) AP for that guest.
* The kernel adjustments (which is the bigger set of changes with 20+ commits) made it in time for mantic into the Ubuntu kernel 6.5 (backports from 6.6), but not the qemu changes.
* This SRU seeks an exception, to add the needed qemu changes post-GA to bring this overall functionality to work, since it's desired to exploit this as part of a product.
[ Fixes ]
* 297ec01f0b s390x/ap: fix missing subsystem reset registration
* ef1535901a s390x: do a subsystem reset before the unprotect on reboot
* da3c22c74a linux-headers: Update to Linux v6.6-rc1
* 354383c122 target/s390x/kvm: Refactor AP functionalities
* 5ac951519c target/s390x: AP-passthrough for PV guests
[ Test Plan ]
* Have an Ubuntu 23.10 LPAR with at least one (better several) APs assigned. Check with:
$ lszcrypt -V
CARD.DOM TYPE MODE STATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER
--------------------------------------------------------------------------------------------
00 CEX7C CCA-Coproc online 1 0 11 08 S--D--N--- cex7card
00.000a CEX/C CCA-Coproc online 1 0 11 08 S--D--N--- cex7queue
* Setup a secure execution environment according to
'Introducing IBM Secure Execution for Linux' (SC34-7721-03)
See PDF page #15 ff, that use Ubuntu as an example.
* Pass selected AP resources from the KVM host through to the Secure Execution (SE) guest.
* Enable the SE guest to make use of hardware cryptographic facilities by installing the needed packages:
$ sudo apt-get install libica-utils libica? openssl-ibmca
and configure openssl:
$ sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf
This allows to make use of the ibmca openssl engine:
$ openssl engine -c
(dynamic) Dynamic engine loading support
(ibmca) Ibmca hardware engine support
[RSA, DSA, DH, RAND, DES-ECB, DES-CBC, DES-OFB, DES-CFB, DES-EDE3, DES-EDE3-CBC, DES-EDE3-OFB,
DES-EDE3-CFB, AES-128-ECB, AES-192-ECB, AES-256-ECB, AES-128-CBC, AES-192-CBC, AES-256-CBC,
AES-128-OFB, AES-192-OFB, AES-256-OFB, AES-128-CFB, AES-192-CFB, AES-256-CFB, SHA1, SHA256, SHA512]
* Reset the icastats crypto counters with (just in case they are not zero):
$ icastats -r
* Consume cryptographic resources in the secure guest that are known to be executed
by the underlying and passed through hardware cryptography.
For example:
$ openssl speed -evp aes-256-cbc 2>/dev/null | tail -n 3
will provide this output:
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
AES-256-CBC 160454.13k 510929.25k 1272902.21k 1590194.94k 1708914.64k 1702523.78k
and will especially lead to icastats counter entries (indicating hardware use) for DRBG-SHA-512:
$ icastats | grep DRBG-SHA-512
DRBG-SHA-512 | 175 | 0
[
Alternatively use ssh to consume hardware crypto, like with (do an 'icastats -r' before):
$ ssh -c chacha20-poly1305@openssh.com ubuntu@localhost
that will lead to these counter entries:
$ icastats | grep 'DRBG-SHA-512\|RSA-ME'
DRBG-SHA-512 | 171 | 0
RSA-ME | 1 | 0
]
* The verification needs to be done by IBM.
[ Where problems could occur ]
* Commits 297ec01f0b and ef1535901a are very small fixes (each one line),
that are pretty traceable.
* Commit da3c22c74a introduces the needed kernel 6.6 header changes.
These fit to the 23.10 kernel (since they were already cherry picked: LP#2003674)
They touch common code files and can potentially affect other architectures.
However, the majority of modification are additional definitions.
* Commits 354383c122 touches the s390x target only,
refactors AP, and changes check, test and set functions.
Hence if done errornously this can lead to a wrong states.
Or if the refactoring wasn't done complete functions might be missed,
but this of course is checked by a test build.
Overall this does not look too invasive.
* Commit 5ac951519c, again touching s390x code only,
is the actual AP-passthrough for PV guests.
It adds this feature similar to other the existing ones, and expands the CPU model.
No code is removed, but only added to existing functions and a new set of
functions got introduced: uv_feat_supported, query_uv_feat_guest, configure_uv_feat_guest
In case of issues with these, query or config of features can be harmed
which might lead to wrong states or even break the code.
[ Other Info ]
* It's for our partner IBM an important new feature (as confidential computing is in general),
which unfortunately landed late in qemu.
* It's with 5 patches (with two of them one line fixes) not very invasive.
* The modification can be and will be thoroughly tested.
__________
Feature Description:
Enable KVM and QEMU for AP passthrough to Secure Execution guests. This includes setup, configuration and teardown of AP related resources. |
|
| 2023-10-19 18:30:12 |
Frank Heimes |
information type |
Private |
Public |
|
| 2023-10-23 08:26:55 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2023-10-23 08:27:04 |
Christian Ehrhardt |
tags |
architecture-s39064 bugnameltc-201348 qemu-24.04 severity-high targetmilestone-inin2404 |
architecture-s39064 bugnameltc-201348 qemu-24.04 server-todo severity-high targetmilestone-inin2404 |
|
| 2023-10-23 09:02:21 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Mantic |
|
| 2023-10-23 09:02:21 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Mantic) |
|
| 2023-10-23 15:52:42 |
Christian Ehrhardt |
qemu (Ubuntu Mantic): assignee |
Skipper Bug Screeners (skipper-screen-team) |
Sergio Durigan Junior (sergiodj) |
|
| 2023-10-31 14:50:55 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/qemu/+git/qemu/+merge/454830 |
|
| 2023-11-03 12:20:12 |
Frank Heimes |
qemu (Ubuntu Mantic): status |
New |
In Progress |
|
| 2023-11-03 12:20:15 |
Frank Heimes |
qemu (Ubuntu): status |
New |
In Progress |
|
| 2023-11-03 12:20:19 |
Frank Heimes |
ubuntu-z-systems: status |
New |
In Progress |
|
| 2023-11-16 15:44:13 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/qemu/+git/qemu/+merge/455724 |
|
