On Mon, Jul 06 2026, Harald Freudenberger <[email protected]> wrote:
> 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. 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.
