Re: [PATCH 2/3] schema: add TPM emulator <source file='..'>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 29, 2024 at 12:04:27PM -0400, Stefan Berger wrote:
> 
> 
> On 8/28/24 11:26 AM, Daniel P. Berrangé wrote:
> > On Wed, Aug 28, 2024 at 11:02:28AM +0400, marcandre.lureau@xxxxxxxxxx wrote:
> > > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>
> > > 
> > > Learn to parse a file path for the TPM state.
> > > 
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx>
> 
> > When we have two different backend options - in this case 'dir' and
> > 'file', then we would normally have an "type" attribute on the parent
> > element, that dictates what child elements are permitted.
> > 
> > Picking a chunk from earlier in the patch:
> > 
> > > +typedef enum {
> > > +    VIR_DOMAIN_TPM_STORAGE_DEFAULT,
> > > +    VIR_DOMAIN_TPM_STORAGE_FILE,
> > > +} virDomainTPMStorage;
> > 
> > I would have expected to see
> > 
> >   typedef enum {
> >       VIR_DOMAIN_TPM_STORAGE_DIR,
> >       VIR_DOMAIN_TPM_STORAGE_FILE,
> >   } virDomainTPMStorage;
> > 
> > 
> > and have this enum be exposed as the 'type' attribute on <backend>.
> > 
> > Also, if we're going to expose the raw file path as a user configurable
> > optin for "file" type, then IMHO, we should also expose the dir path
> > for our existing backend. It doesn't make sense to allow one to be
> > configured, but not both.
> 
> I am not sure whether it is good to give users control over directories or
> file paths. Do we want to allow them to get access to the state of a a TPM
> of another VM?

Libvirt is not responsible for enforcing such policies. A connection to
libvirt which has been granted permission to the change the XML, has
privileges equivalent to an unrestricted root shell.

The mgmt application talking to libvirt is responsible for not making bad
VM configuration decisions, such as giving the VM access to the host /
filesystem or /dev/ inode for host disks. Controlling access to the TPM
paths is inconsequential compared to this and thus providing the ability
to configure TPM state paths has no security implications IMHO.

If there is a need for a virtual TPM that is immune to host administrative
mistakes, then IMHO only confidential computing can offer meaningful
protection. ie a paravisor can securely isolate a vTPM from both the host
OS and guest OS/firmware using the VMPL concept in SEV-SNP on AMD CPUs, or
TDX partitioning on Intel CPUs.

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 :|




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux