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
