On Fri, Aug 09, 2013 at 03:07:13PM +0000, Matthew Garrett wrote: > On Fri, 2013-08-09 at 07:02 -0400, Vivek Goyal wrote: > > On Fri, Aug 09, 2013 at 03:36:37AM -0400, Matthew Garrett wrote: > > > kexec permits the loading and execution of arbitrary code in ring 0, which > > > is something that module signing enforcement is meant to prevent. It makes > > > sense to disable kexec in this situation. > > > > > > > But in the process we wipe out running kernel's context and boot into a new > > kernel. So how different it is than root booting a new kernel through BIOS > > which does not enforce module signing. > > What wipes the current kernel's context? KEXEC_JUMP is explicitly > designed to allow you to hop back and forth, but even without it you > should be able to reconstruct the original context. And there's no need > to boot a new kernel, either. All the attacker needs is the physical > address of the sig_enforce boolean, and then they launch a simple kexec > payload that simply flips that back and returns to the original kernel - > it's not like kexec limits you to booting Linux. > > > Also it would be nice if we introduce new features, then we make other > > features work with those new features instead of disabling existing > > features and leave it to other people to make them work. > > Sure, it'd be nice if security features got introduced with > consideration to other kernel features that allow them to be > circumvented, but this approach seems better than making them > incompatible at the Kconfig level. So how would one go about making kexec work when module signature enforcement is on? I guess same solution which is required to make it work with secureboot. Sign /sbin/kexec and let /sbin/kexec very signature of kernel. IOW, any code which runs at priviliged level should be signature verified with keys in system_keyring. Thanks Vivek
