Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

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

On Wed, Jan 31, 2024 at 01:12:45PM -0800, Dan Williams wrote:
> Daniel P. Berrangé wrote:
> > On Wed, Jan 31, 2024 at 12:44:46PM -0800, Kuppuswamy Sathyanarayanan wrote:
> > > 
> > > On 1/31/24 11:50 AM, Dan Williams wrote:
> > > > Kuppuswamy Sathyanarayanan wrote:
> > > >> + Dan Middleton
> > > >>
> > > >> Hi Boris,
> > > >>
> > > >> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> > > >>> IOCTL based interface was the natural choice for interacting with the
> > > >>> quote generation machine at a time when there wasn't anything better.
> > > >>> Fortunately, now we have a vendor-agnostic, configfs-based one which
> > > >>> obviates the need to have the IOCTL-based interface.
> > > >>>
> > > >>> Gate the relevant code behind a Kconfig option, clearly marking it as
> > > >>> deprecated as well as introduce a runtime warning.
> > > >>>
> > > >>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> > > >>> ---
> > > >> In the following thread, Dan Middleton raised a point about this interface
> > > >> being used for local attestation use cases.
> > > >>
> > > >> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
> > > >>
> > > >> Currently, the configfs-based ABI does not support the local attestation use cases.
> > > > What are local attestation use cases, and what happens if Linux does not
> > > > provide a local attestation interface and standardizes on remotely
> > > > attestable as the standard?
> > > 
> > > 
> > > Local attestation is used by one TD on the same platform to prove to another TD
> > > in the same platform about its identity. It is mainly used in cases where a TD provides
> > > some special services required by other TDs. Since they are all in the same platform,
> > > there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
> > > to check the correctness of the TD.
> > 
> > As an example of where this might be needed, consider supporting a vTPM in
> > TDX. The TPM impl would likely be run in a separate service TD, and need to
> > be locally attested by the primary TD, to establish trust in the vTPM.
> 
> Service TDs are in active deployment? How does that work? A tenant pays
> the fees to host 2 VMs? Is that more economical than just communicating
> the remote verifier? Not trying to be argumentative just trying to get
> to the root of the question "why Linux must care about local
> attestation".

Any VM you buy has host resource overhead beyond the VM's declared resources,
and whether you realize it or not, as a user you are paying for this extra
resource consumption.

With KVM today, vTPM will involve each VM having a separate swtpm process
running alongside QEMU in the host, and of course QEMU itself has resource
consumption which can be fairly significant.  A Cloud provider will have to
take account of the additional per-VM overheads when calculating their
potential host capacity for running VMs & thus setting their VM price. 

In a TDX scenario this separate swtpm turns into something that runs inside
a minimal TDVM instead. The RAM overhead may be larger than with swtpm, but
for a cloud provider its merely one more factor to take account of when
setting their price vs host capacity.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|