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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Jul 06, 2026 at 02:18:25PM +0200, Harald Freudenberger 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.
> 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?

IMHO any use of TCG inherantly throws away any security guarantees
that rely on a guaranteed hardware impl, and in addition we don't
claim that TCG provides a secure host/guest boundary & thus excluded
it from CVE triage.

IOW, if someone is concerned about integrity of their VM, the
answer is to detect the presence of TCG in general, rather than
detect anything related to this narrow protected key feature.

TL;DR: this is at most a docs problem to highlight the limitations
of using TCG in general, and not a problem for this patch series.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|