Messages in this thread | | | Subject | Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot | From | James Bottomley <> | Date | Wed, 15 Aug 2018 14:57:02 -0700 |
| |
On Wed, 2018-08-15 at 17:52 -0400, Vivek Goyal wrote: > On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote: > > On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote: > > > On 15.08.2018 22:47, Linus Torvalds wrote: > > > > It basically says: we don't allow modules that weren't built > > > > with > > > > the kernel. Adding a new key later and signing a module with it > > > > violates that premise. > > > > > > Considering the following scenario: > > > A user is running a distro kernel, which is built by the distro, > > > and has the distro signing key builtin (i.e. fedora). Now, the > > > user has taken ownership of their system and provisioned their > > > own platform key. Accordingly, the user signs the distro kernel > > > with their own key. > > > > > > If I understand you correctly, modules signed by the users own > > > key, but not signed with the distro key, will stop working in > > > this case? > > > > They never actually would have worked, but yes. > > > > > IMO, this is not okay. The layer of trust should extend from the > > > bottom (user-provisioned platform key) up. Only trusting the > > > kernel builtin key later on (wrt. kernel modules) contradicts > > > this principal. > > > > The kernel can't tell whether the UEFI user has taken ownership or > > not so it has no basis on which to make a decision to trust the > > UEFI keys or not, so we should *always* not trust them. > > > > Consider a UEFI system for which a user has taken ownership, but > > which has some signed ROMs which are UEFI secure boot > > verified. Simply to get their system to boot the user will be > > forced to add the ODM key to the UEFI db ... and I'm sure in that > > situation the user wouldn't want to trust the ODM key further than > > booting. > > IIUC, it is fine to trust these ODM keys, User keys and "foo" keys > for loading kernel but not for modules?
It's fine to trust the secure boot keys for the boot environment. If you argue kexec is linux booting linux then yes, that's a supported use.
> If yes, then atleast we can enable trusting keys in > .secondary_trusted_keys keyring for kernel signature verificaton and > that will solve the kexec/kdump issue on distribution kernels.
I think it's OK ... I can't think of any reason you'd want a signed kernel to boot but not to be able to kexec to a kernel with the same signer.
James
| |