Re: [DISCUSSION] svsm: attestation: if and how to authenticate the provided secret

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

On Fri, Oct 17, 2025 at 03:48:38PM -0400, James Bottomley wrote:
> On Fri, 2025-10-17 at 14:47 +0100, Daniel P. Berrangé wrote:
> > On Fri, Oct 17, 2025 at 09:25:18AM -0400, James Bottomley wrote:
> > > On Tue, 2025-10-14 at 21:33 -0400, Tyler Fanelli wrote:
> > > > On 10/14/25 5:40 PM, James Bottomley wrote:
> > > [...]
> > > > > On this, how does the guest know it's pulled in the correct
> > > > > image? If I were a malicious host, I could encrypt my own TPM
> > > > > image, accept your attestation to a KBS I control and release a
> > > > > key that decrypts my malicious image.  I think you give the
> > > > > answer below:
> > > > > 
> > > > 
> > > > We intend for the guest's rootfs to be sealed to the persistent
> > > > TPM found in encrypted storage. The malicious host could switch
> > > > the TPM, but that TPM wouldn't be able to unseal the rootfs.
> > > > 
> > > > This doesn't directly prevent the attack you mention above, but
> > > > it would be a DoS.
> > > 
> > > Not necessarily.  If I control the host, I also control what you
> > > boot in all stages.  If you simply take booting up as proof, then I
> > > can substitute both the KBS and the boot system, so you'll boot
> > > with my image but if you're running a trusted service in the VM,
> > > it's now my service.  An examination of the launch measurement by a
> > > trusted KBS would defeat this, which is why I substituted the KBS
> > > as well.
> > > 
> > > The point being that there has to be validation on both sides.  If
> > > you want a KBS to deliver a boot key by which your boot sequence
> > > continuing is your validation, you still need to prove that you
> > > contacted the correct KBS in the first place otherwise your launch
> > > measurement might not actually have been validated.
> > 
> > For protection aganist that threat the guest owner would need to
> > validate either the TPM identity, or the root FS identity, or both,
> > once the VM is first accessed after booting.
> > 
> > In the root FS case, systemd measures the primary encryption key of
> > any unlocked LUKS volume into PCR 15. If the user has prior knowledge
> > of the expected hash they can use a TPM quote to validate that the
> > root FS volume has not been substituted, and in turn that validates
> > that the TPM state has not been substituted as the LUKS keyslot would
> > have been sealed to the TPM.
> 
> I agree this would work ... but it's a who guards the guards problem
> and the above solution needs another guard to guard the first one (the
> KBS).

The problem might be pushed even further up the stack to the application
level. For example, the authentic disk image is likely to contain one, or
more secrets which cannot be replicated by the person substituting the
fake TPM state & root FS. The SSH host key is one example, but HTTPS
server certificates might be another.

> Another possible solution, which allows the KBS to be the only guard,
> is to have the KBS launch the VM, meaning it knows it should get a
> launch measurement back from the launched VM to release keys and can
> shut it down if it doesn't.

Injecting the KBS into the VM launch sequence feels like it could be
a challenge to integrate, if it makes the CVM launch flow significantly
different from the regular VM launch flow.

Overall the intent of the SVSM pre-boot attestation was to make it
easy to shift all workloads between traditional VMs and CVMs, without
imposing mandatory special steps on guest owners - they would want to
opt-in to full validation if their usage demands that level of extra
assurance. 

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