[Xen-devel] RFC Xen signature verification for kexec

[Jan Beulich]

>>> On 23.04.18 at 12:25, <daniel.kiper at oracle.com> wrote:
> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>> >>> 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.
> 
> Hmmm... Is not it a problem from security point of view for us in this
> case? It should not if dom0 kernel is signed. It have to be signed here.
> Just thinking a loud...

I'm afraid I don't understand: If the Dom0 kernel isn't signed (or hasn't
been verified), the system is insecure in the first place. No reason to
bother measuring the kexec kernel then.

>> > #####
>> > 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
> 
> I do not think that we care about kernel modules format here...

This was just meant to give an example of a case where PE is not required
for carrying certificates.

Jan