On Mon, Sep 26, 2022 at 08:47:32AM +0200, Greg Kroah-Hartman wrote:
> On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote:
> > On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote:
> > > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote:
> > > > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote:
> > > > > > Hello,
> > > > > >
> > > > > > this is backport of commit 0d519cadf751
> > > > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature")
> > > > > > to table 5.15 tree including the preparatory patches.
> > > > >
> > > > > This feels to me like a new feature for arm64, one that has never worked
> > > > > before and you are just making it feature-parity with x86, right?
> > > > >
> > > > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and
> > > > > why can't people who need this new feature just use a newer kernel
> > > > > version (5.19?)
> > > >
> > > > It's half-broken implementation of the kexec kernel verification. At the time
> > > > it was implemented for arm64 we had the platform and secondary keyrings
> > > > and x86 was using them but on arm64 the initial implementation ignores
> > > > them.
> > >
> > > Ok, so it's something that never worked. Adding support to get it to
> > > work doesn't really fall into the stable kernel rules, right?
> >
> > Not sure. It was defective, not using the facilities available at the
> > time correctly. Which translates to kernels that can be kexec'd on x86
> > failing to kexec on arm64 without any explanation (signed with same key,
> > built for the appropriate arch).
>
> Feature parity across architectures is not a "regression", but rather a
> "this feature is not implemented for this architecture yet" type of
> thing.
That depends on the view - before kexec verification you could boot any
kernel, now you can boot some kernels signed with a valid key, but not
others - the initial implementation is buggy, probably because it
is based on an old version of the x86 code.
>
> > > Again, what's wrong with 5.19 for anyone who wants this? Who does want
> > > this?
> >
> > Not sure, really.
> >
> > The final patch was repeatedly backported to stable and failed to build
> > because the prerequisites were missing.
>
> That's because it was tagged, but now that you show the full set of
> requirements, it's pretty obvious to me that this is not relevant for
> going this far back.
That also works.
Thanks
Michal
