RE: Coconut-SVSM - vTPM support for Intel TD Partitioning

[Claudio Siqueira de Carvalho <cclaudio@ibm.com>]

On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> > [...]
> > > > 
> > > > That brings me to a curious point: is the Intel TDX SVSM going to
> > > > follow the SVSM protocol interface?  because if it is, it will
> > > > naturally inherit the enlightened interface (the code will be
> > > > present in the kernel, so it only needs activating).  However, if
> > > > the Intel SVSM were going to ignore the SVSM protocol spec then it
> > > > would have to reinvent everything and the CRB interface might make
> > > > more sense.
> > > 
> > > I cannot speak on behalf of the Intel TDX *SVSM* implementation, but
> > > for the Linux guest kernel there is no intention at the moment to
> > > support smth like SVSM protocol interface. We have made an evaluation
> > > on this during the spring. There are no usecases currently that
> > > require such new protocol introduction on Intel TDX and it does bring
> > > additional code complexity, etc.
> > > If anyone believes otherwise, please let me know.
> > 
> > If you reinvent the vTPM communication interface, I can see you are
> > able to get away without that SVSM communication component.
> 
> The goal is exactly the opposite, i.e. don't reinvent anything, but
> try to stick with exiting ways on how we have been doing things so far in
> Linux. In this light SVSM is an invention to do things.

How will Intel attest the SVSM services provided? In addition to the core
protocol and the VTPM protocol, the SVSM spec 1.0 also define the ATTEST
protocol which can be used to get an attestation report for the SVSM services,
endorsing the supported services and their respective payloads. The payload for
the VTPM service is the SVSM-vTPM EK pub.

Regards,
Claudio

> 
> 
>  I assume
> > you've done the same for other SVSM provided services like
> > deposit/remove memory and vcpu create/delete, but what about migration
> > when it comes along? 
> 
> Could you please give an example of where let's say we are not ok with
> existing Linux ways of depositing/removing memory? Why do we need
> to create a new protocol like SVSM from guest kernel for doing this?
> It can be done if there is a valid usecase of course. All I am saying is that
> we haven’t found any yet.
> 
>  Since the high level operations will be pretty
> > much identical on AMD and Intel it would be very annoying to have to do
> > it in completely different ways (with presumably different tools).
> 
> Migration is a separate story, which i dont think has any conclusion yet
> or agreement in the community. We (Intel TDX) have a way to migrate
> the guest without the guest assistance, so we dont have a strict requirement
> to migrate out of SVSM. It remains to be seen what method(s) is to be 
> selected at the end. And if svsm-based migration method is going to be
> supported for intel tdx, then it needs a separate analysis to determine
> what is the actual required communication between the L2 guest and
> SVSM in our case and whenever the usage of the SVSM-style protocol
> is necessary.  
> 
> Imo migration is one of the topics that would be great to discuss at LPC.
> 
> Best Regards,
> Elena. 
> 
> > 
> > Regards,
> > 
> > James
>