[Xen-devel] RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 20.04.18 at 21:12, <eric.devolder at oracle.com> wrote:
> Two options for signature verification in Xen
> 
> This proposal outlines two options under consideration for enhancing
> Xen to support signature verification of kexec loaded images. The
> first option is essentially to mirror Linux signature verification
> code into Xen. The second option utilizes components from sources
> other than Linux (for example, libgcrypt rather than linux/crypto).
> 
> NOTE: An option to utilize dom0 kernel signature verification does not
> prevent the exploit as user space can invoke the hypercall directly,
> bypassing dom0.

Not exactly - this option nevertheless exists, albeit is perhaps
unattractive: No user space component can issue hypercalls
directly, they always go through the privcmd driver. Hence the
driver cold snoop the kexec hypercall.

> #####
> Option 2: Enable signature verification in Xen utilizing libgcrypt
> 
> This option is similar to Option 1, but utilizes libgcrypt
> crytpo library rather than linux/crypto files.
> 
> Pros:
> - Libgcrypt is LGPLv2.1+ license.
> - Eliminates problematic scenario of tracking changes to
>    linux/crypto sources in Xen, and vice versa in Linux.

As an initial reaction, of the two options presented I'd prefer this
2nd one, for this specific reason.

> Cons:
> - Introduces a dependency on libgcrypt
> - Still relying on lifting many Linux kernel sources for PE file
>    handling, certificate handling, etc. However, an alternative
>    source for PE file handling is shim.

That's under the assumption that PE files are the only containers usable
to carry certificates, which I consider odd, not the least because Linux
kernel modules aren't PE either. If the kernel was carrying its certificate
in a way (also) accessible without parsing PE structures, this dependency
could be dropped.

Jan