diff for duplicates of <1468845964.2800.3.camel@gmail.com> diff --git a/a/1.txt b/N1/1.txt index d95d657..19faff2 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -70,8 +70,3 @@ do the magic for you. So its not always physical access, is it? I agree, if you can change command line arguments, all bets are of lesser value Balbir Singh - -_______________________________________________ -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 2936234..a39811d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -17,14 +17,14 @@ "Cc\0Stewart Smith <stewart@linux.vnet.ibm.com>" bhe@redhat.com arnd@arndb.de - kexec@lists.infradead.org - dyoung@redhat.com Petr Tesarik <ptesarik@suse.cz> + 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 + dyoung@redhat.com " linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" @@ -99,11 +99,6 @@ "\n" "I agree, if you can change command line arguments, all bets are of lesser value\n" "\n" - "Balbir Singh\n" - "\n" - "_______________________________________________\n" - "kexec mailing list\n" - "kexec@lists.infradead.org\n" - http://lists.infradead.org/mailman/listinfo/kexec + Balbir Singh -769b6771e877ee8155b10ea4ce1e2d6f428adc3546c119c9f72641161ef72cf5 +86b9ac9bc98da0429bac3fda03fea95818fef3e13cbeb87249d41d37e4fe6f99
diff --git a/a/1.txt b/N2/1.txt index d95d657..b3d4fc6 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,28 +1,28 @@ 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 @@ -31,18 +31,18 @@ that you can get a module to load with another attack > > > 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 @@ -52,26 +52,21 @@ that you can get a module to load with another attack 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, +? +> >? +> >? +> > 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 Balbir Singh - -_______________________________________________ -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 2936234..a79cc13 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -9,50 +9,37 @@ "ref\020160713130338.GB16900@redhat.com\0" "ref\020160713174009.GA1041@n2100.armlinux.org.uk\0" "ref\020160713182247.GA25232@redhat.com\0" - "From\0Balbir Singh <bsingharora@gmail.com>\0" - "Subject\0Re: [RFC 0/3] extend kexec_file_load system call\0" + "From\0bsingharora@gmail.com (Balbir Singh)\0" + "Subject\0[RFC 0/3] extend kexec_file_load system call\0" "Date\0Mon, 18 Jul 2016 22:46:04 +1000\0" - "To\0Vivek Goyal <vgoyal@redhat.com>" - " Russell King - ARM Linux <linux@armlinux.org.uk>\0" - "Cc\0Stewart Smith <stewart@linux.vnet.ibm.com>" - bhe@redhat.com - arnd@arndb.de - kexec@lists.infradead.org - dyoung@redhat.com - Petr Tesarik <ptesarik@suse.cz> - 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 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" @@ -61,18 +48,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" @@ -82,28 +69,23 @@ "\n" "You don't need physical access -- your machine controller BMC can\n" "do the magic for you. So its not always physical access, is it?\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" - "Balbir Singh\n" - "\n" - "_______________________________________________\n" - "kexec mailing list\n" - "kexec@lists.infradead.org\n" - http://lists.infradead.org/mailman/listinfo/kexec + Balbir Singh -769b6771e877ee8155b10ea4ce1e2d6f428adc3546c119c9f72641161ef72cf5 +39cb57a429b49127200bfb751b30b42b8f516c98acb2997bc1b60cb645407a6e
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.