On Thu, 2012-11-01 at 14:57 +0000, Matthew Garrett wrote: > On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote: > > > And if one wants only /sbin/kexec to call it, then just sign that > > one so no other executable will be able to call kexec_load(). Though > > I don't think that's the requirement here. Requirement is that only > > trusted executables should be able to call kexec_load(). > > Where "trusted executables" means "signed by a key that's present in the > system firmware or in the kernel that's signed with a key that's present > in the system firmware", sure. > This is starting to sound too restrictive (even though I understand the rationale behind the restrictions). Does this allow for a custom userspace application that among other things also can kexec_load() a new kernel and boot it, for example a customer unique health monitoring app that reboots the system if things are not looking right on the running system? How would a customer go about getting that userspace binary signed and re-signed every time they update their app? There is the option of turning the whole SecureBoot thing off for a system like that but let us assume customer wants to leave that on or does not have the option to turn it off? -- Khalid
