[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC Xen signature verification for kexec
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. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |