From: Philipp Rudo <prudo@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: Jan Hendrik Farr <kernel@jfarr.cc>,
Pingfan Liu <kernelfans@gmail.com>,
linux-arm-kernel@lists.infradead.org, linux-efi@vger.kernel.org,
kexec@lists.infradead.org, Pingfan Liu <piliu@redhat.com>,
Baoquan He <bhe@redhat.com>, Ard Biesheuvel <ardb@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
keyrings@vger.kernel.org, Luca Boccassi <bluca@debian.org>,
lennart@poettering.net, Jarkko Sakkinen <jarkko@kernel.org>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org, mjg59@google.com,
James.Bottomley@hansenpartnership.com
Subject: Re: [PATCH 0/2] Sign the Image which is zboot's payload
Date: Mon, 25 Sep 2023 17:24:32 +0200 [thread overview]
Message-ID: <20230925172432.78b45f80@rotkaeppchen> (raw)
In-Reply-To: <CALu+AoQHZOBcbCJJnhSyEcTyX6C3VttLxMKt2mdHgT7A6xHN9w@mail.gmail.com>
Hi Dave,
On Fri, 22 Sep 2023 13:41:22 +0800
Dave Young <dyoung@redhat.com> wrote:
> Hi Jan,
>
> On Fri, 22 Sept 2023 at 13:19, Jan Hendrik Farr <kernel@jfarr.cc> wrote:
> >
> > Hi Pingfan!
> >
> > On 21 21:37:01, Pingfan Liu wrote:
> > > From: Pingfan Liu <piliu@redhat.com>
> > >
> >
> > > For security boot, the vmlinuz.efi will be signed so UEFI boot loader
> > > can check against it. But at present, there is no signature for kexec
> > > file load, this series makes a signature on the zboot's payload -- Image
> > > before it is compressed. As a result, the kexec-tools parses and
> > > decompresses the Image.gz to get the Image, which has signature and can
> > > be checked against during kexec file load
> >
> > I missed some of the earlier discussion about this zboot kexec support.
> > So just let me know if I'm missing something here. You were exploring
> > these two options in getting this supported:
> >
> > 1. Making kexec_file_load do all the work.
> >
> > This option makes the signature verification easy. kexec_file_load
> > checks the signature on the pe file and then extracts it and does the
> > kexec.
> >
> > This is similar to how I'm approaching UKI support in [1].
> >
> > 2. Extract in userspace and pass decompressed kernel to kexec_file_load
> >
> > This options requires the decompressed kernel to have a valid signature on
> > it. That's why this patch adds the ability to add that signature to the
> > kernel contained inside the zboot image.
> >
> > This option would not make sense for UKI support as it would not
> > validate the signature with respect to the initrd and cmdline that it
> > contains.
>
> Another possibility for the cmdline could be using the bootconfig
> facility which was
> introduced for boot time tracking:
> Documentation/admin-guide/bootconfig.rst
>
> So the initrd+cmdline can be signed as well. Has this been discussed
> before for UKI?
Not that I know of. But I'm not sure if the bootconfig the way it works
today does the trick.
For one the bootconfig is simply glued to the end of the initrd. But
that makes it part of the UKI as well. So there is no added gain.
Plus, adding the cmdline to the UKI was done on purpose to prevent any
unauthorized editing. That basically means that any change to the
cmdline needs to be signed as well. But I don't see any signature
verification while processing the bootconfig.
Finally the bootconfig is setup too late in the boot process,
in particular after setup_arch which reserves the crashkernel
memory and needs to parse the kernel command line for that. An even more
extreme example is the decompressor phase on s390. There the command
line is parsed as well. And that is code that runs before start_kernel.
All in all I don't believe that using the bootconfig adds much benefit
for the UKI.
Thanks
Philipp
next prev parent reply other threads:[~2023-09-25 15:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230921133703.39042-1-kernelfans@gmail.com>
2023-09-22 5:19 ` [PATCH 0/2] Sign the Image which is zboot's payload Jan Hendrik Farr
2023-09-22 5:41 ` Dave Young
2023-09-25 15:24 ` Philipp Rudo [this message]
2023-09-25 3:01 ` Pingfan Liu
2023-09-25 8:55 ` Ard Biesheuvel
2023-09-27 23:46 ` Jan Hendrik Farr
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=20230925172432.78b45f80@rotkaeppchen \
--to=prudo@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ardb@kernel.org \
--cc=bhe@redhat.com \
--cc=bluca@debian.org \
--cc=catalin.marinas@arm.com \
--cc=dyoung@redhat.com \
--cc=jarkko@kernel.org \
--cc=kernel@jfarr.cc \
--cc=kernelfans@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=lennart@poettering.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mjg59@google.com \
--cc=piliu@redhat.com \
--cc=will@kernel.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 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 NNTP newsgroup(s).