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

[Simon Horman <horms@xxxxxxxxxxxx>]

On Tue, Jan 15, 2019 at 04:41:19PM +0100, Daniel Kiper wrote:
> On Tue, Jan 15, 2019 at 03:15:28PM +0100, Simon Horman wrote:
> > On Mon, Jan 14, 2019 at 01:52:07PM -0600, Eric DeVolder wrote:
> > > These changes work in conjunction with the signature
> > > verification support for Xen I published recently.
> > >
> > > Prior to this change, kexec supported the following
> > > three modes of operation:
> > >
> > > kexec_load:
> > > - unverified loading of kernel into Linux (original mode)
> > > - unverified loading of kernel into Xen
> > > kexec_file_load (the -s option to kexec):
> > > - verified loading of kernel into Linux
> > >
> > > With the verified loading of a kernel into Linux, the scope
> > > of kexec changed drastically as the kernel performs most of
> > > the work that kexec previously did; the kernel does so so as
> > > to reduce the risk of compromise.
> > >
> > > For example, the unverified loading of a kernel into Linux
> > > involves locating memory within the system to load the
> > > various pieces of data (kernel, initramdisk, command line)
> > > as well as reserving additional memory such as the first 1MB
> > > on x86 for legacy reasons as well as something known as
> > > 'purgatory', a trampoline that checks the integrity of the
> > > contents of loaded pieces of data, before invoking that
> > > loaded kernel. The management of purgatory involves
> > > manipulating an embedded ELF purgatory object file to insert
> > > a memory hash value, and rewrite a few run-time switches
> > > based on kexec command line parameters.
> > >
> > > By contrast, the verified loading essentially just passes
> > > file handles for the kernel, initramdisk, and command line
> > > pointer, and the kernel takes care of the rest, by
> > > performing all the work that the unverified kexec load would
> > > do, but inside the kernel using trusted kernel code.
> > >
> > > This changeset adds a fourth mode to kexec:
> > >
> > > - verified loading of kernel into Xen
> > >
> > > In general, Xen performs the signature verification on the
> > > loaded kernel, much as Linux does, but that is where the
> > > similarities end.  In the current Xen implementation, no
> > > infrastructure is present to support reading from [Linux
> > > dom0] file handles, or for manipulating ELF objects. As
> > > such, without Xen support for these actions, Xen relies upon
> > > kexec to provide these services, which is what this mode
> > > does.
> > >
> > > To achieve this, this mode of operation essentially vectors
> > > the verified load for Xen through the non-verified path,
> > > which performs all the needed actions for kexec to work, but
> > > then makes an adjustment to pass the entire kernel file, not
> > > just the loadable portion of the kernel file, to Xen in
> > > order to provide the proper image for signature
> > > verification.
> > >
> > > The loading of kexec images for signature verification for
> > > Xen is indicated with the -s switch, just like for Linux.
> > >
> > > Changes to configure.ac are for detecting whether or not the
> > > Xen version supports this kexec_file_load hypercall op.
> > >
> > > Changes to kexec-bzImage64.c are for recording what the
> > > change to the kernel image entry needs to be (the entire
> > > kernel file, not just the loadable portion), as well as
> > > vectoring kexec_file_load through kexec_load for Xen.
> > >
> > > Changes to kexec-xen.c are to invoke the new Xen
> > > kexec_file_load hypercall op, from kexec_load.
> > >
> > > Changes to kexec.c are to vector kexec_file_load for Xen
> > > throgh kexec_load for Xen, as well as make the correction
> > > for passing the complete kernel file to Xen.
> > >
> > > Signed-off-by: Eric DeVolder <eric.devolder@xxxxxxxxxx>
> >
> > Thanks Eric,
> >
> > this looks good to me, aside from one nit below.
> 
> Please do not apply this patch. This is an RFC.
> 
> Eric, thank you for doing this work.

Thanks Daniel, noted.

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