kexec_load(2) bypasses signature verification

[Petr Tesarik]

On Mon, 15 Jun 2015 17:11:00 +0800
Dave Young <dyoung at redhat.com> wrote:

> On 06/14/15 at 11:50pm, Theodore Ts'o wrote:
> > From experimentation and from looking at the sources, it appears that
> > the signature checking is only done in the kexec_file_load(2) system
> > all, and not in the kexec_load(2) system call.  And I understand why
> > -- the signature is not sent from userspace to the kernel in the older
> > kexec_load(2) system call.
> > 
> > The problem is that if you use an old version of kexec, it will use
> > the old kexec_load(2) system call, and even though
> > CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an
> > unsigned kernel, and then "kexec -e" will happily boot into it.
> > 
> > Correct me if I am wrong, but this appears to be a hole in Secure Boot
> > you could drive a Mack Truck through.
> > 
> > (I noticed this because Debian is still using a kexec-tools from the
> > stone ages, version 2.0.7, and I was wondering **why** I was able to
> > kexec boot completely unsigned kernels.)
> > 
> > It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the
> > old kexec_load(2) system call should be disabled (and a warning be
> > placed in the Kconfig help that the user should have at least verision
> > 2.X of kexec-tools if they enable this kernel option).
> 
> IMO it is fine to disable old syscall incase CONFIG_KEXEC_VERIFY=y

Definitely. It is not possible to to sign all code passed through
kexec_load(2), at least not without giving kexec-tools the private part
of the key (which would effectively destroy the goal of Secure Boot).

Whenever signature verification is required, kexec_load(2) must be
disabled.

Petr Tesarik