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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.04.18 at 12:13, <daniel.kiper@xxxxxxxxxx> wrote:
> On Tue, Apr 24, 2018 at 10:46:38AM +0100, George Dunlap wrote:
>> 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.
> 
> I have a feeling that I should reformulate the question: How far the Xen
> hypervisor trusts the privcmd driver? If the privcmd driver is signed
> then at first sight there should not be a problem. However, we can be
> more strict and require that (every? Daniel is running away...) hypercall
> from privcmd to Xen should be verified somehow. Maybe I am overzealous but
> I think that it make sense to discuss this now than later have problems.

An analogy of this would be that every system call needs verifying by the
OS, which imo would be insane. Once we established trust in a component,
we _should_ trust it.

Jan



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