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