On Fri, Nov 02, 2012 at 02:36:11PM -0700, H. Peter Anvin wrote: > On 10/22/2012 02:15 PM, Eric W. Biederman wrote: > >> > >> This is like re-designing the kexec/kdump and I really wish there is > >> an easier way to handle the case signed kernels. > > > > Yes. Which is why either a signed puragtory or a signed /sbin/kexec > > look very attractive. > > > > Signed purgatory sounds like The Right Thing. Doing relocation in > purgatory should be quite trivial; I'd be happy to work with people if > they need pointers how to do it. So we sign purgatory and do the relocations in kernel later after signature verification? I have few questions though. - We modify purgatory (update symbol values) in user space. That allows us to build single purgatory and chagne its behavior based on user options to kexec-tools (like 16bit vs 32bit entry, updating location of backup region etc). In fact purgatory to kernel jump location is decided at run time and purgatory is updated accordingly. That means we can't sign the purgatory. So apart from relocation, user space modification of purgatory code is also an issue. - Even if we come up with a way to avoid that, so will we not sign /sbin/kexec in that case? What happens to other unsigned segments loaded by /sbin/kexec. (boot_params, command line, elf headers etc). Can these be trusted without any signature. So I am not sure that just signing the purgatory will solve the issue. Thanks Vivek
