From: James Bottomley <jejb@linux.ibm.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Jörg Rödel" <jroedel@suse.de>,
"Christophe de Dinechin Dupont de Dinechin" <cdupontd@redhat.com>,
linux-coco@lists.linux.dev, amd-sev-snp@lists.suse.com
Subject: Re: SVSM initiated early attestation / guest secrets injection
Date: Fri, 20 Jan 2023 12:10:34 -0500 [thread overview]
Message-ID: <a60f7cc2814b7d4bd7b4cc876634ff18276e0965.camel@linux.ibm.com> (raw)
In-Reply-To: <Y8qON8v5DmB+u9u3@redhat.com>
On Fri, 2023-01-20 at 12:51 +0000, Daniel P. Berrangé wrote:
> On Fri, Jan 20, 2023 at 07:39:30AM -0500, James Bottomley wrote:
> > On Fri, 2023-01-20 at 08:57 +0000, Daniel P. Berrangé wrote:
> > > On Fri, Jan 20, 2023 at 09:37:35AM +0100, Jörg Rödel wrote:
> > > > On Thu, Jan 19, 2023 at 04:29:23PM -0500, James Bottomley
> > > > wrote:
> > > > > How can they stay there? Even if the SVSM is the point of
> > > > > first contact to receive the secret, it must give the secret
> > > > > to higher VMPLs to try the mount, so the higher VMPLs have to
> > > > > destroy the secret they were given on failure.
> > > >
> > > > My thinking was that the SVSM will only hand out the secrets
> > > > once the code in higher VMPLs has proven itself to be trusted.
> > > > But it is possible for an attacker to create an image with the
> > > > expected parts to get the measurements right and then use a
> > > > fall-back mount if decryption fails to steal the secret.
> > >
> > > With a vTPM, and systemd-pcrphase.service, it is possible to seal
> > > secrets to prevent such an attack, by including phase=initrd in
> > > the sealing PCRs. IOW, nothing after the initrd can unseal the
> > > secrets, even if a different filesystem mount was substituted.
> > >
> > > Secrets that are needed /after/ the root FS is mounted (eg SSH
> > > host key, Apache HTTP certs) can be sealed with a PCR set that
> > > covers the LUKS master key hash, so that they can only be
> > > acccessed if the correct rootfs was unlocked.
> >
> > But that provides no additional security: the LUKS master hash is
> > just a hash of an area on the disk which anyone controlling the
> > device can see. I can duplicate this area and still substitute my
> > own volume (which would still fail to decrypt when presented with
> > the key), so the trusted mounting component sill has to correctly
> > handle the failure case.
>
> Yes, it would have to be a hash that is different from the
> hash that's exposed in clear text in the LUKS header.
True, but whatever thing you has hash to be available to the trusted
mounting entity before the secret is released, so all it can know are
what an observer can see ... there's no other thing you can hash that
the trusted mounting component knows that an observer can't see as
well.
> For example it could be hash(master_key || uuid).
The hash could only contain master_key if the secret is already
released, so you can't condition the key release on this hash.
James
next prev parent reply other threads:[~2023-01-20 17:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 14:39 SVSM initiated early attestation / guest secrets injection Daniel P. Berrangé
2023-01-13 17:22 ` Jörg Rödel
2023-01-13 18:02 ` James Bottomley
2023-01-14 16:57 ` Jörg Rödel
2023-01-19 14:05 ` Christophe de Dinechin Dupont de Dinechin
2023-01-19 14:10 ` James Bottomley
2023-01-19 21:18 ` Jörg Rödel
2023-01-19 21:29 ` James Bottomley
2023-01-20 8:37 ` Jörg Rödel
2023-01-20 8:57 ` Daniel P. Berrangé
2023-01-20 12:39 ` James Bottomley
2023-01-20 12:51 ` Daniel P. Berrangé
2023-01-20 17:10 ` James Bottomley [this message]
2023-01-20 12:32 ` James Bottomley
2023-01-13 18:28 ` Daniel P. Berrangé
2023-01-13 18:52 ` Dionna Amalie Glaze
2023-01-16 9:36 ` Daniel P. Berrangé
2023-01-14 17:08 ` Jörg Rödel
2023-01-14 18:22 ` James Bottomley
2023-01-16 16:55 ` Jörg Rödel
2023-01-16 16:59 ` James Bottomley
2023-01-17 16:47 ` Jörg Rödel
2023-01-16 17:13 ` Daniel P. Berrangé
2023-01-17 16:53 ` Jörg Rödel
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=a60f7cc2814b7d4bd7b4cc876634ff18276e0965.camel@linux.ibm.com \
--to=jejb@linux.ibm.com \
--cc=amd-sev-snp@lists.suse.com \
--cc=berrange@redhat.com \
--cc=cdupontd@redhat.com \
--cc=jroedel@suse.de \
--cc=linux-coco@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).