On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > >? > > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > > >? > > > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > > > >? > > > > Indeed - maybe Eric knows better, but I can't see any situation where > > > > the dtb we load via kexec should ever affect "the bootloader", unless > > > > the "kernel" that's being loaded into kexec is "the bootloader". > > > >? > > > > Now, going back to the more fundamental issue raised in my first reply, > > > > about the kernel command line. > > > >? > > > > On x86, I can see that it _is_ possible for userspace to specify a > > > > command line, and the kernel loading the image provides the command > > > > line to the to-be-kexeced kernel with very little checking.??So, if > > > > your kernel is signed, what stops the "insecure userspace" loading > > > > a signed kernel but giving it an insecure rootfs and/or console? > > > It is not kexec specific. I could do this for regular boot too, right? > > >? > > > Command line options are not signed. I thought idea behind secureboot > > > was to execute only trusted code and command line options don't enforce > > > you to execute unsigned code. > > >? You can set module.sig_enforce=0 and open up the system a bit assuming that you can get a module to load with another attack > > > So it sounds like different class of security problems which you are > > > referring to and not necessarily covered by secureboot or signed > > > kernel. > > Let me give you an example. > >? > > You have a secure boot setup, where the firmware/ROM validates the boot > > loader.??Good, the boot loader hasn't been tampered with. > >? > > You interrupt the boot loader and are able to modify the command line > > for the booted kernel. > >? > > The boot loader loads the kernel and verifies the kernel's signature. > > Good, the kernel hasn't been tampered with.??The kernel starts running. > >? > > You've plugged in a USB drive to the device, and specified a partition > > containing a root filesystem that you control to the kernel.??The > > validated kernel finds the USB drive, and mounts it, and executes > > your own binaries on the USB drive. > You will require physical access to the machine to be able to > insert your usb drive. And IIRC, argument was that if attacker has > physical access to machine, all bets are off anyway. > You don't need physical access -- your machine controller BMC can do the magic for you. So its not always physical access, is it? ? > >? > >? > > You run a shell on the console.??You now have control of the system, > > and can mount the real rootfs, inspect it, and work out what it does, > > etc. > >? > > At this point, what use was all the validation that the secure boot > > has done???Absolutely useless. > >? > > If you can change the command line arguments given to the kernel, you > > have no security, no matter how much you verify signatures.??It's > > the illusion of security, nothing more, nothing less. > >? I agree, if you can change command line arguments, all bets are of lesser value Balbir Singh
