All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Tyler Fanelli <tfanelli@redhat.com>,
	Nicolai Stange <nstange@suse.de>,
	Oliver Steffen <osteffen@redhat.com>,
	Stefano Garzarella <sgarzare@redhat.com>,
	coconut-svsm@lists.linux.dev
Subject: Re: [DISCUSSION] svsm: attestation: if and how to authenticate the provided secret
Date: Fri, 17 Oct 2025 14:47:43 +0100	[thread overview]
Message-ID: <aPJI_5t8IO_zVM3P@redhat.com> (raw)
In-Reply-To: <8d76ade860b2ccc2ffbed5a5e6f73a8357776522.camel@HansenPartnership.com>

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.

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


  reply	other threads:[~2025-10-17 13:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14  8:45 [DISCUSSION] svsm: attestation: if and how to authenticate the provided secret Nicolai Stange
2025-10-14 19:23 ` James Bottomley
2025-10-14 20:56   ` Nicolai Stange
2025-10-14 21:40     ` James Bottomley
2025-10-15  1:33       ` Tyler Fanelli
2025-10-17 11:31         ` Nicolai Stange
2025-10-17 13:25         ` James Bottomley
2025-10-17 13:47           ` Daniel P. Berrangé [this message]
2025-10-17 19:48             ` James Bottomley
2025-10-24 12:17               ` Daniel P. Berrangé
     [not found]         ` <91799.125101707314800421@us-mta-315.us.mimecast.lan>
2025-10-17 16:16           ` Tyler Fanelli
2025-10-17 12:30       ` Nicolai Stange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aPJI_5t8IO_zVM3P@redhat.com \
    --to=berrange@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=coconut-svsm@lists.linux.dev \
    --cc=nstange@suse.de \
    --cc=osteffen@redhat.com \
    --cc=sgarzare@redhat.com \
    --cc=tfanelli@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.