Re: [PATCH v10 10/21] target/s390x: Base support for cpacf protected keys

[Harald Freudenberger <freude@linux.ibm.com>]

On 2026-07-06 13:51, Cornelia Huck wrote:
> On Mon, Jul 06 2026, Harald Freudenberger <freude@linux.ibm.com> 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 <freude@linux.ibm.com>
>> ---
>>  target/s390x/tcg/cpacf.h     | 25 +++++++++++++++++++++++
>>  target/s390x/tcg/cpacf_aes.c | 39 
>> ++++++++++++++++++++++++++++++++++++
>>  2 files changed, 64 insertions(+)