On 2026-07-06 13:51, Cornelia Huck wrote:
On Mon, Jul 06 2026, Harald Freudenberger <[email protected]> wrote:
Add base support for cpacf protected key handling.
The qemu version provided here is only a fake intended to make
protected key available for developing and testing purpose:
* The protected key is 'derived' from the clear key by xoring
the fixed pattern 0xAAAA... onto the key value.
* The AES Wrapping Key Verification Pattern is a fixed
value of 32 bytes 0xFACEFACE...
Add preprocessor defines for the xor pattern and wkvp used to
construct ('encrypt') a protected key from a clear key value with
this implementation. Also add some static functions to 'encrypt'
from clear key to protected key and 'decrypt' back to cpacf_aes.c.
The preprocessor defines shall be used later in testcases to
construct and decode protected keys.
Hmm... so does that mean that we only provide the protected key
handling
in the !KVM case for people who want to run via tcg for some
development
purposes? Does the user actually get some kind of notice in that case,
if for example they run with !KVM due to some configuration hiccup?
IOW,
do users get some clue that they are running with a fake placeholder
implementation, other than the setup being slow?
Well, there are 2 paths leading to protected use:
1) you have a secure key and want to 'derive' a protected key from that
to operate faster. This is for example the case now when you have an
PAES encrypted filesystem.
In such a case you need a crypto card with the Master Key setting
fitting to when your secure key was generated.
-> this is not a practical way for qemu on !KVM as you need a crypto
card AND the s390 firmware stack.
2) you 'derive' a protected key from a clear key value. On a s390 system
this is done via the privileged instruction PCKMO. On this qemu with
!KVM this is the fake I implemented.
In general it is absolutely not recommended to go this path as the
source
of the key is/was/needs to stay in OS memory. So you don't win any
security by using protected keys this way - in fact you would have
done better to just use the clear key as it is. Please note also,
that
by default this path on a s390 system is disabled - however, for
testing
purpose there are ways to use it this way.
However, this is exactly what this implementation here is for. For
testing
purpose you may 'derive' a protected key from clear key or any other
way
as the algorithm to derive is clear documented here. And then you can
play
around and run tests with protected key implementations.
I see your point: How can a innocent user see that his/her vm is running
with
this fake installation instead of the real one. The answer is:
If the source of the protected key is a secure key - then there is no
path
on the faked implementation to get a hand on a protected key.
If the source of the protected key is a clear key - honestly does it
even
matter which implementation is then running?
Hopefully I could explain the difference.
Signed-off-by: Harald Freudenberger <[email protected]>
---
target/s390x/tcg/cpacf.h | 25 +++++++++++++++++++++++
target/s390x/tcg/cpacf_aes.c | 39
++++++++++++++++++++++++++++++++++++
2 files changed, 64 insertions(+)
