>>> On 20.04.18 at 21:12, <eric.devol...@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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
