From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Michael Roth <michael.roth@amd.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, eduardo@habkost.net,
armbru@redhat.com, pankaj.gupta@amd.com, huibo.wang@amd.com,
jroedel@suse.com, dionnaglaze@google.com
Subject: Re: [PATCH v1 3/3] i386/sev: Add KVM_EXIT_SNP_REQ_CERTS support for certificate-fetching
Date: Thu, 19 Dec 2024 18:01:14 +0000 [thread overview]
Message-ID: <Z2RfamsMDDI5Jo0E@redhat.com> (raw)
In-Reply-To: <20241219174949.wtmw7gosb4hkfjxg@amd.com>
On Thu, Dec 19, 2024 at 11:49:49AM -0600, Michael Roth wrote:
> On Thu, Dec 19, 2024 at 01:37:18PM +0000, Daniel P. Berrangé wrote:
> > IMHO we msut consider unlink() to be a valid thing, because the right
> > way for apps to perform crash safe atomic updates of existing files,
> > is to use rename() from a temporary file, and the rename() in has an
> > implicit unlink as part of its operation. ie apps would be doing:
> >
> > fd = open("foo.tmp")
> > write(fd, ...)
> > fsync(fd)
> > close(fd)
> > rename("foo.tmp", "foo")
>
> If we still want to allow for this rather than enforcing in-place
> update, one alternative would be to just allow a separate lock file
> to be specified rather than locking the certificate file itself. That
> would provide a bit more flexibility.
>
> I can update the QEMU implementation to take -certs-lock-file in
> addition to -certs-file so they can be specified separately. And if
> -certs-lock-file is not specified then QEMU will just assume
> management handles things different or has agreed to not do endorsement
> key updates while SNP guests are running.
>
> I think we'd considered something like that originally but the thinking
> was that locking the certs themselves was more organic in terms of an
> "obvious"/natural solution. But it does end up being a bit more
> inflexible WRT how libraries/etc. might manage file updates underneath
> the covers, so maybe a lock file is the better approach after all.
If we want locking, I think locking the certs file directly is a nicer
idea, as it avoids everyone having to agree on the location of the
lock file, relative to the certs file.
The current locking code just needs to go inside a while(1) loop and
have fstat + stat added to detect the recreation race. For example:
https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virpidfile.c#L376
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 :|
next prev parent reply other threads:[~2024-12-19 18:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 15:49 [PATCH RFC v1 0/3] SEV-SNP: Add support for SNP certificate fetching Michael Roth
2024-12-18 15:49 ` [PATCH v1 1/3] linux-headers: Update for 6.12 and SNP certificate support Michael Roth
2024-12-18 15:49 ` [PATCH v1 2/3] accel/kvm: Add kvm_immediate_exit callback infrastructure Michael Roth
2024-12-18 15:49 ` [PATCH v1 3/3] i386/sev: Add KVM_EXIT_SNP_REQ_CERTS support for certificate-fetching Michael Roth
2024-12-18 17:32 ` Markus Armbruster
2024-12-18 22:14 ` Michael Roth
2024-12-18 17:50 ` Daniel P. Berrangé
2024-12-18 22:29 ` Michael Roth via
2024-12-19 8:13 ` Daniel P. Berrangé
2024-12-19 13:16 ` Michael Roth via
2024-12-19 13:37 ` Daniel P. Berrangé
2024-12-19 17:49 ` Michael Roth via
2024-12-19 18:01 ` Daniel P. Berrangé [this message]
2025-02-05 18:04 ` Liam Merwick
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=Z2RfamsMDDI5Jo0E@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=dionnaglaze@google.com \
--cc=eduardo@habkost.net \
--cc=huibo.wang@amd.com \
--cc=jroedel@suse.com \
--cc=michael.roth@amd.com \
--cc=pankaj.gupta@amd.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.