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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
