Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag

[David Gibson]

On Tue, Jan 19, 2021 at 09:16:08AM +0100, Cornelia Huck wrote:
> On Mon, 18 Jan 2021 19:47:30 +0000
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> 
> > * David Gibson (david@gibson.dropbear.id.au) wrote:
> > > The platform specific details of mechanisms for implementing
> > > confidential guest support may require setup at various points during
> > > initialization.  Thus, it's not really feasible to have a single cgs
> > > initialization hook, but instead each mechanism needs its own
> > > initialization calls in arch or machine specific code.
> > > 
> > > However, to make it harder to have a bug where a mechanism isn't
> > > properly initialized under some circumstances, we want to have a
> > > common place, relatively late in boot, where we verify that cgs has
> > > been initialized if it was requested.
> > > 
> > > This patch introduces a ready flag to the ConfidentialGuestSupport
> > > base type to accomplish this, which we verify just before the machine
> > > specific initialization function.  
> > 
> > You may find you need to define 'ready' and the answer might be a bit
> > variable; for example, on SEV there's a setup bit and then you may end
> > up doing an attestation and receiving some data before you actaully let
> > the guest execute code.   Is it ready before it's received the
> > attestation response or only when it can run code?
> > Is a Power or 390 machine 'ready' before it's executed the magic
> > instruction to enter the confidential mode?
> 
> I would consider those machines where the guest makes the transition
> itself "ready" as soon as everything is set up so that the guest can
> actually initiate the transition. Otherwise, those machines would never
> be "ready" if the guest does not transition.
> 
> Maybe we can define "ready" as "the guest can start to execute in
> secure mode", where "guest" includes the bootloader and everything that
> runs in a guest context, and "start to execute" implies that some setup
> may be done only after the guest has kicked it off?

That was pretty much my intention.  I've put a big comment on the
field definition and tweaked things around a bit in the hopes of
making that clearer for the next spin.


-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature