From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>,
xen-devel@lists.xenproject.org,
Kevin Lampis <kevin.lampis@cloud.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Anthony PERARD <anthony.perard@vates.tech>,
Michal Orzel <michal.orzel@amd.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v3 2/5] livepatch: Embed public key in Xen
Date: Fri, 20 Jun 2025 12:33:26 +0200 [thread overview]
Message-ID: <aFU49lNOoQXxWf9N@macbook.local> (raw)
In-Reply-To: <aa1354da-46d1-4867-9a51-1b6b00ceb50b@suse.com>
On Fri, Jun 20, 2025 at 12:09:21PM +0200, Jan Beulich wrote:
> On 20.06.2025 11:39, Roger Pau Monné wrote:
> > On Mon, Jun 02, 2025 at 02:36:34PM +0100, Ross Lagerwall wrote:
> >> From: Kevin Lampis <kevin.lampis@cloud.com>
> >>
> >> Make it possible to embed a public key in Xen to be used when verifying
> >> live patch payloads. Inclusion of the public key is optional.
> >>
> >> To avoid needing to include a DER / X.509 parser in the hypervisor, the
> >> public key is unpacked at build time and included in a form that is
> >> convenient for the hypervisor to consume. This is different approach
> >> from that used by Linux which embeds the entire X.509 certificate and
> >> builds in a parser for it.
> >>
> >> A suitable key can be created using openssl:
> >>
> >> openssl req -x509 -newkey rsa:2048 -keyout priv.pem -out pub.pem \
> >> -sha256 -days 3650 -nodes \
> >> -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"
> >> openssl x509 -inform PEM -in pub.pem -outform PEM -pubkey -nocert -out verify_key.pem
> >>
> >> Signed-off-by: Kevin Lampis <kevin.lampis@cloud.com>
> >> Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
> >> ---
> >>
> >> In v3:
> >>
> >> * Drop unnecessary condition in Makefile
> >> * Use dashes instead of underscores
> >> * Drop section placement annotation on declaration
> >> * Clarify endianness of embedded key
> >>
> >> xen/common/Kconfig | 18 +++++++++++++++++
> >> xen/crypto/Makefile | 11 ++++++++++
> >> xen/include/xen/livepatch.h | 5 +++++
> >> xen/tools/extract-key.py | 40 +++++++++++++++++++++++++++++++++++++
> >> 4 files changed, 74 insertions(+)
> >> create mode 100755 xen/tools/extract-key.py
> >>
> >> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> >> index 0951d4c2f286..74673078202a 100644
> >> --- a/xen/common/Kconfig
> >> +++ b/xen/common/Kconfig
> >> @@ -472,6 +472,24 @@ config LIVEPATCH
> >>
> >> If unsure, say Y.
> >>
> >> +config PAYLOAD_VERIFY
> >> + bool "Verify signed LivePatch payloads"
> >> + depends on LIVEPATCH
> >> + select CRYPTO
> >> + help
> >> + Verify signed LivePatch payloads using an RSA public key built
> >> + into the Xen hypervisor. Selecting this option requires a
> >> + public key in PEM format to be available for embedding during
> >> + the build.
> >> +
> >> +config PAYLOAD_VERIFY_KEY
> >> + string "File name of public key used to verify payloads"
> >> + default "verify_key.pem"
> >> + depends on PAYLOAD_VERIFY
> >> + help
> >> + The file name of an RSA public key in PEM format to be used for
> >> + verifying signed LivePatch payloads.
> >
> > I think this is likely to break the randconfig testing that we do in
> > Gitlab CI, as randconfig could select PAYLOAD_VERIFY, but there will
> > be no key included, and hence the build will fail?
> >
> > Ideally Gitlab CI would need to be adjusted to provide such key so the
> > build doesn't fail. I think it could be provided unconditionally to
> > simplify the logic, if the option is not selected the file will simply
> > be ignored.
>
> Alternatively the two options could be folded, the default being the
> empty string meaning "no payload verification". I don't think randconfig
> can sensibly make up random strings ...
Could be an option. Not sure if the menu interface would then look a
bit weird. IMO it's a nicer UI to enable the option and then get
asked for the cert to use rather than bundling everything in a single
string-like option.
Thanks, Roger.
next prev parent reply other threads:[~2025-06-20 10:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-02 13:36 [PATCH v3 0/5] LivePatch signing support Ross Lagerwall
2025-06-02 13:36 ` [PATCH v3 1/5] docs: Introduce live patch signing Ross Lagerwall
2025-06-02 13:36 ` [PATCH v3 2/5] livepatch: Embed public key in Xen Ross Lagerwall
2025-06-05 11:02 ` Jan Beulich
2025-06-05 11:19 ` Jan Beulich
2025-06-20 9:42 ` Roger Pau Monné
2025-06-20 9:39 ` Roger Pau Monné
2025-06-20 10:09 ` Jan Beulich
2025-06-20 10:33 ` Roger Pau Monné [this message]
2025-06-02 13:36 ` [PATCH v3 3/5] crypto: Add RSA support Ross Lagerwall
2025-06-05 11:06 ` Jan Beulich
2025-06-20 9:53 ` Roger Pau Monné
2025-06-20 16:11 ` Ross Lagerwall
2025-06-23 7:28 ` Jan Beulich
2025-06-02 13:36 ` [PATCH v3 4/5] livepatch: Load built-in key during boot Ross Lagerwall
2025-06-05 11:17 ` Jan Beulich
2025-06-02 13:36 ` [PATCH v3 5/5] livepatch: Verify livepatch signatures Ross Lagerwall
2025-06-05 11:52 ` Jan Beulich
2025-06-20 10:31 ` Roger Pau Monné
2025-06-20 16:50 ` Ross Lagerwall
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=aFU49lNOoQXxWf9N@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=kevin.lampis@cloud.com \
--cc=michal.orzel@amd.com \
--cc=ross.lagerwall@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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.