Re: [Xen-devel] RFC Xen signature verification for kexec

[George Dunlap <dunlapg@xxxxxxxxx>]

On Mon, Apr 23, 2018 at 11:33 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 23.04.18 at 12:25, <daniel.kiper@xxxxxxxxxx> wrote:
>> On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote:
>>> >>> On 20.04.18 at 21:12, <eric.devolder@xxxxxxxxxx> 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.

I think you're both saying the same thing.

FWIW I wouldn't mind coming up with a hypercall that the privcmd
driver refuses to pass-through as-is, and having some way for the
tools to ask the kernel to check the signature.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel