Re: How to list keys used for kexec

[Guozihua (Scott)]

On 2022/4/26 16:52, Michal Suchánek wrote:
> On Tue, Apr 26, 2022 at 12:10:13PM +0800, Guozihua (Scott) wrote:
> > On 2022/4/15 1:59, Michal Suchánek wrote:
> > > Hello,
> > >
> > > apparently modules are verified by keys from 'secondary' keyring on all
> > > platforms.
> > >
> > > If you happen to know that it's this particular keyring, and know how
> > > to list keyrings recursively you can find the keys that are used for
> > > verifying modules.
> > >
> > > However, for kexec we have
> > >
> > >    - primary keyring on aarch64
> > >    - platform keyring on s390
> > >    - secondary AND platform keyring on x86
> > >
> > > How is a user supposed to know which keys are used for kexec image
> > > verification?
> > >
> > > There is an implicit keyring that is ad-hoc constructed by the code that
> > > does the kexec verification but there is no key list observable from
> > > userspace that corresponds to this ad-hoc keyring only known to the kexec
> > > code.
> > >
> > > Can the kernel make the information which keys are used for what purpose
> > > available to the user?
> > >
> > > Thanks
> > >
> > > Michal
> > >
> > > .
> >
> > Hi Michal
> >
> > I'll try my best to understand and answer your question.
> >
> > First of all, the "key" you mentioned here is actually certificate. And
> > there are no way for the kernel to know "which certificate is used for what
> > purpose" but to get a hint from the certificate's extension, if they exist.
> > However, the extension only points out what this certificate should be used
> > for, but not exactly what it is actually used for.
>
> > Secondly, the verification process requires the module (kernel image in this
> > question) to contain information on which certificate should be used to
> > verify itself. The signature provided by the module is in PKCS#7 format
> > which contains a list of certificates for the verifier to construct a "chain
> > of trust". Each certificates contains information pointing to the
> > certificate of it's issuer, and eventually to one of the certificate stored
> > in one of the keyrings you mentioned.
>
> Indeed, that's not really relevant to this problem.
> Sure, if the certificates extension does exist and does not state that
> the certificate can be used for code signing then the signature should
> be rejected. The same if the signature is malformed and does not provide
> enough information to determine which key was used to create it.
>
> The question which key will be checked, though.
> > All in all, certificates in these keyrings you mentioned can be used for
> > various purpose, and it's the responsibility for the modules being verified
> > to provide information stating which certificate should be used for
> > verification. Thus, the best way to find out which key is used for kexec is
> > to look at key used to sign the kernel image.
>
> There aren't really good tools for working with the kernel signatures
> but I can tell what certificate it was signed with jumping throught some
> hoops.
>
> What I can't tell without reading the kernel code (different for each
> architecture) is what certificates the kernel considers valid for
> signing kernels. The kernel surely knows but does not tell.

It's quite true on this one, maybe some documentation would help.
> That is, for example, if I have a known bad kernel I want to be able to
> tell if it's loadable without actually loading it.

For this you can try the -l option with kexec which loads the kernel but 
will not execute it. And then you can use -u option to unload the kernel 
again and see whether it resolves your requirement.
> Thanks
>
> Michal
> .

--
Best
GUO Zihua