Re: [PATCH v3 2/5] livepatch: Embed public key in Xen

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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@xxxxxxxxx>
> >>
> >> 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@xxxxxxxxx>
> >> Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> >> ---
> >>
> >> 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.