On Tue, Oct 23, 2012 at 11:11:05PM +0400, Maxim Uvarov wrote: > 2012/10/23 Vivek Goyal <vgoyal at redhat.com>: > > On Tue, Oct 23, 2012 at 09:26:32AM -0700, Eric W. Biederman wrote: > > > > [..] > >> > I think this will be a new parallel path and this new path should be taken > >> > only on kernel booted with secure boot enabled. (Either automatically or > >> > by using some kexec command line option). So nothing should be broken > >> > because we never supported anything on secure boot enabled system. > >> > >> Rubbish. Kexec works just fine today on a secure boot enabled system. > >> Ignoring the nonsense that there is no such thing as a secure boot > >> enabled linux system. > > > > I think it is a security hole for the systems where we don't want to run > > unsigned priviliged code. So yes, it works as of today, but at some point > > of time we shall have to close this hole. > > > > Thanks > > Vivek > > > Signatures kernel & modules in general good for support reason. We can > say for example that we support only signed kernel and signed modules > for that kernel, so we are sure that this binaries match our source. > But what is the reason of checking signatures in kexec? If you have > root privileges then more likely you have access to boot loader or to > physical machine (console, bios). Might be useful only for embedded > things to prevent enthusiasts play with already manufactured devices. The way I understand is that we don't allow any unsigned code to run at priviliged level. That's why early from boot everything is signed, that includes shim, bootloader, kernel and modules. User space code does not run with privilige, so it is let run without being signed. Why do it, matthew has explained here in his blog. http://mjg59.dreamwidth.org/9844.html Thanks Vivek
