On Wed, Jan 10, 2018 at 12:59:52PM +0100, Takashi Iwai wrote:
I think that KEXEC_VERIFY_SIG should be similarly split to KEXEC_SIG and KEXEC_SIG_FORCE and we should not compile with KEXEC_SIG_FORCE. The signing would again be enforced by kernel_is_locked_down.
Does that make sense?
One difference in the case of kexec is that there are actually two routes, and one could use the old kexec method for unsigned kernels. And, as discussed in bsc#947816, a part of the problem is that user-space doesn't treat it properly without fallback mechanism.
yes, but falling back to a completely different API just because
the new API only accepts a signed kernel seems wrong.
With secureboot, we now put
if (kernel_is_locked_down()) return -EPERM;
into the kexec_load syscall to completely disable it when
secureboot is on. That's fine, because this syscall can not check
signatures at all. With secureboot off this syscall works.
Yet in the kexec_file_load syscall we force the verification even
without secure boot and that seems wrong.
I would prefer:
- without secure boot: both kexec_load and kexec_file_load work
and ignore the signature
- with secure boot: only kexec_file_load works and requires a
valid signature
--
Jiri Bohac