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

[Cornelia Huck <cohuck@redhat.com>]

On Mon, Jul 06 2026, Harald Freudenberger <freude@linux.ibm.com> wrote:

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

Nod.

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

Yes, and it is useful for that.

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

Yes, thanks.

It seems we have similar cases for other archs, so let's just keep it as
it is now.