diff for duplicates of <20160718133824.GC32512@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 16067d3..8ea82ca 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -100,8 +100,3 @@ Vivek > are not covered by secureboot model. > > Vivek - -_______________________________________________ -kexec mailing list -kexec@lists.infradead.org -http://lists.infradead.org/mailman/listinfo/kexec diff --git a/a/content_digest b/N1/content_digest index 158a8e3..1fd8bad 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -12,20 +12,20 @@ "Subject\0Re: [RFC 0/3] extend kexec_file_load system call\0" "Date\0Mon, 18 Jul 2016 09:38:24 -0400\0" "To\0Balbir Singh <bsingharora@gmail.com>\0" - "Cc\0Stewart Smith <stewart@linux.vnet.ibm.com>" - mjg59@srcf.ucam.org + "Cc\0Russell King - ARM Linux <linux@armlinux.org.uk>" + Stewart Smith <stewart@linux.vnet.ibm.com> bhe@redhat.com arnd@arndb.de - kexec@lists.infradead.org - dyoung@redhat.com Petr Tesarik <ptesarik@suse.cz> - Russell King - ARM Linux <linux@armlinux.org.uk> + linuxppc-dev@lists.ozlabs.org + kexec@lists.infradead.org linux-kernel@vger.kernel.org AKASHI Takahiro <takahiro.akashi@linaro.org> Eric W. Biederman <ebiederm@xmission.com> Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - linuxppc-dev@lists.ozlabs.org - " linux-arm-kernel@lists.infradead.org\0" + dyoung@redhat.com + linux-arm-kernel@lists.infradead.org + " mjg59@srcf.ucam.org\0" "\00:1\0" "b\0" "On Mon, Jul 18, 2016 at 09:26:29AM -0400, Vivek Goyal wrote:\n" @@ -129,11 +129,6 @@ "> 0, then it is a problem. Otherwise we are talking of security issues which\n" "> are not covered by secureboot model.\n" "> \n" - "> Vivek\n" - "\n" - "_______________________________________________\n" - "kexec mailing list\n" - "kexec@lists.infradead.org\n" - http://lists.infradead.org/mailman/listinfo/kexec + > Vivek -9fe93e5ab3d391e5f13942fc36e7303ef74da7614462c18da8de314bc59a6756 +2701100512bcd2dc34bdeaca9fee117a68a68abf60e85f791e663f8299e6ff47
diff --git a/a/1.txt b/N2/1.txt index 16067d3..8d85cb0 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -2,29 +2,29 @@ On Mon, Jul 18, 2016 at 09:26:29AM -0400, Vivek Goyal wrote: > On Mon, Jul 18, 2016 at 10:46:04PM +1000, Balbir Singh wrote: > > 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 +> > > > > > 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 @@ -51,18 +51,18 @@ Vivek > > > > > 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. -> > > > +> > > > 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. -> > > > +> > > > 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 +> > > > 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 @@ -78,20 +78,20 @@ Vivek > code at ring level 0, its a problem I think from secureboot model of > security. > -> > -> > > > -> > > > -> > > > You run a shell on the console. You now have control of the system, +> > ? +> > > >? +> > > >? +> > > > 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. -> > > > +> > > > 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 +> > > > 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 > @@ -100,8 +100,3 @@ Vivek > are not covered by secureboot model. > > Vivek - -_______________________________________________ -kexec mailing list -kexec@lists.infradead.org -http://lists.infradead.org/mailman/listinfo/kexec diff --git a/a/content_digest b/N2/content_digest index 158a8e3..e92e84b 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -8,53 +8,39 @@ "ref\020160713182247.GA25232@redhat.com\0" "ref\01468845964.2800.3.camel@gmail.com\0" "ref\020160718132629.GB32512@redhat.com\0" - "From\0Vivek Goyal <vgoyal@redhat.com>\0" - "Subject\0Re: [RFC 0/3] extend kexec_file_load system call\0" + "From\0vgoyal@redhat.com (Vivek Goyal)\0" + "Subject\0[RFC 0/3] extend kexec_file_load system call\0" "Date\0Mon, 18 Jul 2016 09:38:24 -0400\0" - "To\0Balbir Singh <bsingharora@gmail.com>\0" - "Cc\0Stewart Smith <stewart@linux.vnet.ibm.com>" - mjg59@srcf.ucam.org - bhe@redhat.com - arnd@arndb.de - kexec@lists.infradead.org - dyoung@redhat.com - Petr Tesarik <ptesarik@suse.cz> - Russell King - ARM Linux <linux@armlinux.org.uk> - linux-kernel@vger.kernel.org - AKASHI Takahiro <takahiro.akashi@linaro.org> - Eric W. Biederman <ebiederm@xmission.com> - Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - linuxppc-dev@lists.ozlabs.org - " linux-arm-kernel@lists.infradead.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Mon, Jul 18, 2016 at 09:26:29AM -0400, Vivek Goyal wrote:\n" "> On Mon, Jul 18, 2016 at 10:46:04PM +1000, Balbir Singh wrote:\n" "> > On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote:\n" "> > > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote:\n" - "> > > >\302\240\n" + "> > > >?\n" "> > > > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote:\n" - "> > > > >\302\240\n" + "> > > > >?\n" "> > > > > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote:\n" - "> > > > > >\302\240\n" + "> > > > > >?\n" "> > > > > > Indeed - maybe Eric knows better, but I can't see any situation where\n" "> > > > > > the dtb we load via kexec should ever affect \"the bootloader\", unless\n" "> > > > > > the \"kernel\" that's being loaded into kexec is \"the bootloader\".\n" - "> > > > > >\302\240\n" + "> > > > > >?\n" "> > > > > > Now, going back to the more fundamental issue raised in my first reply,\n" "> > > > > > about the kernel command line.\n" - "> > > > > >\302\240\n" + "> > > > > >?\n" "> > > > > > On x86, I can see that it _is_ possible for userspace to specify a\n" "> > > > > > command line, and the kernel loading the image provides the command\n" - "> > > > > > line to the to-be-kexeced kernel with very little checking.\302\240\302\240So, if\n" + "> > > > > > line to the to-be-kexeced kernel with very little checking.??So, if\n" "> > > > > > your kernel is signed, what stops the \"insecure userspace\" loading\n" "> > > > > > a signed kernel but giving it an insecure rootfs and/or console?\n" "> > > > > It is not kexec specific. I could do this for regular boot too, right?\n" - "> > > > >\302\240\n" + "> > > > >?\n" "> > > > > Command line options are not signed. I thought idea behind secureboot\n" "> > > > > was to execute only trusted code and command line options don't enforce\n" "> > > > > you to execute unsigned code.\n" - "> > > > >\302\240\n" + "> > > > >?\n" "> > \n" "> > You can set module.sig_enforce=0 and open up the system a bit assuming\n" "> > that you can get a module to load with another attack\n" @@ -81,18 +67,18 @@ "> > > > > referring to and not necessarily covered by secureboot or signed\n" "> > > > > kernel.\n" "> > > > Let me give you an example.\n" - "> > > >\302\240\n" + "> > > >?\n" "> > > > You have a secure boot setup, where the firmware/ROM validates the boot\n" - "> > > > loader.\302\240\302\240Good, the boot loader hasn't been tampered with.\n" - "> > > >\302\240\n" + "> > > > loader.??Good, the boot loader hasn't been tampered with.\n" + "> > > >?\n" "> > > > You interrupt the boot loader and are able to modify the command line\n" "> > > > for the booted kernel.\n" - "> > > >\302\240\n" + "> > > >?\n" "> > > > The boot loader loads the kernel and verifies the kernel's signature.\n" - "> > > > Good, the kernel hasn't been tampered with.\302\240\302\240The kernel starts running.\n" - "> > > >\302\240\n" + "> > > > Good, the kernel hasn't been tampered with.??The kernel starts running.\n" + "> > > >?\n" "> > > > You've plugged in a USB drive to the device, and specified a partition\n" - "> > > > containing a root filesystem that you control to the kernel.\302\240\302\240The\n" + "> > > > containing a root filesystem that you control to the kernel.??The\n" "> > > > validated kernel finds the USB drive, and mounts it, and executes\n" "> > > > your own binaries on the USB drive.\n" "> > > You will require physical access to the machine to be able to\n" @@ -108,20 +94,20 @@ "> code at ring level 0, its a problem I think from secureboot model of\n" "> security.\n" "> \n" - "> > \302\240\n" - "> > > >\302\240\n" - "> > > >\302\240\n" - "> > > > You run a shell on the console.\302\240\302\240You now have control of the system,\n" + "> > ?\n" + "> > > >?\n" + "> > > >?\n" + "> > > > You run a shell on the console.??You now have control of the system,\n" "> > > > and can mount the real rootfs, inspect it, and work out what it does,\n" "> > > > etc.\n" - "> > > >\302\240\n" + "> > > >?\n" "> > > > At this point, what use was all the validation that the secure boot\n" - "> > > > has done?\302\240\302\240Absolutely useless.\n" - "> > > >\302\240\n" + "> > > > has done???Absolutely useless.\n" + "> > > >?\n" "> > > > If you can change the command line arguments given to the kernel, you\n" - "> > > > have no security, no matter how much you verify signatures.\302\240\302\240It's\n" + "> > > > have no security, no matter how much you verify signatures.??It's\n" "> > > > the illusion of security, nothing more, nothing less.\n" - "> > > >\302\240\n" + "> > > >?\n" "> > \n" "> > I agree, if you can change command line arguments, all bets are of lesser value\n" "> \n" @@ -129,11 +115,6 @@ "> 0, then it is a problem. Otherwise we are talking of security issues which\n" "> are not covered by secureboot model.\n" "> \n" - "> Vivek\n" - "\n" - "_______________________________________________\n" - "kexec mailing list\n" - "kexec@lists.infradead.org\n" - http://lists.infradead.org/mailman/listinfo/kexec + > Vivek -9fe93e5ab3d391e5f13942fc36e7303ef74da7614462c18da8de314bc59a6756 +0dc2a7c51777f402ba3947a6122d899a3be2f52624b7057fbb1e8e7e5cfe9dbf
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.