Re: [PATCH 2/3] schema: add TPM emulator <source file='..'>
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(a)redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau(a)redhat.com>
> >
> > Learn to parse a file path for the TPM state.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com>
> 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 :|