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