Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1441013 > unrolled thread
| Started by | AKASHI Takahiro <takahiro.akashi@linaro.org> |
|---|---|
| First post | 2016-07-12 03:40 +0200 |
| Last post | 2016-07-13 15:30 +0200 |
| Articles | 20 on this page of 70 — 14 participants |
Back to article view | Back to linux.kernel
[RFC 0/3] extend kexec_file_load system call AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-12 03:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-12 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-12 16:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-12 16:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 01:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-12 16:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-12 16:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-12 16:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-12 17:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-13 04:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 10:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 11:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 15:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-13 20:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 22:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-14 04:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-14 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 03:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-15 09:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-15 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-15 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 17:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-15 17:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-15 15:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-15 22:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 23:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-22 02:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Jeremy Kerr <jeremy.kerr@au1.ibm.com> - 2016-07-22 03:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Michael Ellerman <michael@ellerman.id.au> - 2016-07-22 05:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-22 22:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-15 10:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-15 15:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 11:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-13 19:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 20:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 22:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-14 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-14 04:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-14 04:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-12 18:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-12 23:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-12 23:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-13 00:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-13 00:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 00:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 07:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 09:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-07-13 09:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 10:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-13 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-13 11:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 19:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 20:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Balbir Singh <bsingharora@gmail.com> - 2016-07-18 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-18 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-18 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Balbir Singh <bsingharora@gmail.com> - 2016-07-20 05:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-20 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-20 13:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-20 18:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-20 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-20 14:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 01:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:30 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Dave Young <dyoung@redhat.com> |
|---|---|
| Date | 2016-07-14 04:00 +0200 |
| Message-ID | <rUE6t-2Rt-3@gated-at.bofh.it> |
| In reply to | #1442260 |
On 07/13/16 at 10:34am, Mark Rutland wrote: > On Wed, Jul 13, 2016 at 10:36:14AM +0800, Dave Young wrote: > > But consider we can kexec to a different kernel and a different initrd so there > > will be use cases to pass a total different dtb as well. > > It depends on what you mean by "a different kernel", and what this > implies for the DTB. > I thought about kexec as a boot loader just like other bootloaders. So just like a normal boot kexec should also accept external dtb. But acutally kexec is different because it can get original dtb and use it. So I agreed if we can not find a real use case that we have to extend it we should keep current interface. > I expect future arm64 Linux kernels to function with today's DTBs, and > the existing boot protocol. The kexec_file_load syscall already has > enough information for the kernel to inject the initrd and bootargs > properties into a DTB. > > In practice on x86 today, kexec_file_load only supports booting to a > Linux kernel, because the in-kernel purgatory only implements the x86 > Linux boot protocol. Analagously, for arm64 I think that the first > kernel should use its internal copy of the boot DTB, with /chosen fixed > up appropriately, assuming the next kernel is an arm64 Linux image. > > If booting another OS, the only parts of the DTB I would expect to > change are the properties under chosen, as everything else *should* be > OS-independent. However the other OS may have a completely different > boot protocol, might not even take a DTB, and will likely need a > compeltely different purgatory implementation. So just allowing the DTB > to be altered isn't sufficient for that case. > > There might be cases where we want a different DTB, but as far as I can > tell we have nothing analagous on x86 today. If we do need this, we > should have an idea of what real case(s) were trying to solve. Agreed. Thanks Dave
[toc] | [prev] | [next] | [standalone]
| From | Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-12 18:30 +0200 |
| Message-ID | <rU8Jk-7nR-21@gated-at.bofh.it> |
| In reply to | #1441358 |
Hi Eric, I'm trying to understand your concerns leading to your nack. I hope you don't mind expanding your thoughts on them a bit. Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > AKASHI Takahiro <takahiro.akashi@linaro.org> writes: > > Device tree blob must be passed to a second kernel on DTB-capable > > archs, like powerpc and arm64, but the current kernel interface > > lacks this support. > > > > This patch extends kexec_file_load system call by adding an extra > > argument to this syscall so that an arbitrary number of file descriptors > > can be handed out from user space to the kernel. > > > > See the background [1]. > > > > Please note that the new interface looks quite similar to the current > > system call, but that it won't always mean that it provides the "binary > > compatibility." > > > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html > > So this design is wrong. The kernel already has the device tree blob, > you should not be extracting it from the kernel munging it, and then > reinserting it in the kernel if you want signatures and everything to > pass. I don't understand how the kernel signature will be invalidated. There are some types of boot images that can embed a device tree blob in them, but the kernel can also be handed a separate device tree blob from firmware, the boot loader, or kexec. This latter case is what we are discussing, so we are not talking about modifying an embedded blob in the kernel image. > What x86 does is pass it's equivalent of the device tree blob from one > kernel to another directly and behind the scenes. It does not go > through userspace for this. > > Until a persuasive case can be made for going around the kernel and > probably adding a feature (like code execution) that can be used to > defeat the signature scheme I am going to nack this. I also don't understand what you mean by code execution. How does passing a device tree blob via kexec enables code execution? How can the signature scheme be defeated? -- []'s Thiago Jung Bauermann IBM Linux Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Petr Tesarik <ptesarik@suse.cz> |
|---|---|
| Date | 2016-07-12 23:00 +0200 |
| Message-ID | <rUcWD-1C4-65@gated-at.bofh.it> |
| In reply to | #1441537 |
On Tue, 12 Jul 2016 13:25:11 -0300 Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote: > Hi Eric, > > I'm trying to understand your concerns leading to your nack. I hope you > don't mind expanding your thoughts on them a bit. > > Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > > AKASHI Takahiro <takahiro.akashi@linaro.org> writes: > > > Device tree blob must be passed to a second kernel on DTB-capable > > > archs, like powerpc and arm64, but the current kernel interface > > > lacks this support. > > > > > > This patch extends kexec_file_load system call by adding an extra > > > argument to this syscall so that an arbitrary number of file descriptors > > > can be handed out from user space to the kernel. > > > > > > See the background [1]. > > > > > > Please note that the new interface looks quite similar to the current > > > system call, but that it won't always mean that it provides the "binary > > > compatibility." > > > > > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html > > > > So this design is wrong. The kernel already has the device tree blob, > > you should not be extracting it from the kernel munging it, and then > > reinserting it in the kernel if you want signatures and everything to > > pass. > > I don't understand how the kernel signature will be invalidated. > > There are some types of boot images that can embed a device tree blob in > them, but the kernel can also be handed a separate device tree blob from > firmware, the boot loader, or kexec. This latter case is what we are > discussing, so we are not talking about modifying an embedded blob in the > kernel image. > > > What x86 does is pass it's equivalent of the device tree blob from one > > kernel to another directly and behind the scenes. It does not go > > through userspace for this. > > > > Until a persuasive case can be made for going around the kernel and > > probably adding a feature (like code execution) that can be used to > > defeat the signature scheme I am going to nack this. > > I also don't understand what you mean by code execution. How does passing a > device tree blob via kexec enables code execution? How can the signature > scheme be defeated? I'm not an expert on DTB, so I can't provide an example of code execution, but you have already mentioned the /chosen/linux,stdout-path property. If an attacker redirects the bootloader to an insecure console, they may get access to the system that would otherwise be impossible. In general, tampering with the hardware inventory of a machine opens up a security hole, and one must be very cautious which modifications are allowed. You're giving this power to an (unsigned, hence untrusted) userspace application; Eric argues that only the kernel should have this power. Just my two cents, Petr T
[toc] | [prev] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2016-07-12 23:40 +0200 |
| Message-ID | <rUdzk-25m-17@gated-at.bofh.it> |
| In reply to | #1441732 |
Petr Tesarik <ptesarik@suse.cz> writes: > On Tue, 12 Jul 2016 13:25:11 -0300 > Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote: > >> Hi Eric, >> >> I'm trying to understand your concerns leading to your nack. I hope you >> don't mind expanding your thoughts on them a bit. >> >> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: >> > AKASHI Takahiro <takahiro.akashi@linaro.org> writes: >> > > Device tree blob must be passed to a second kernel on DTB-capable >> > > archs, like powerpc and arm64, but the current kernel interface >> > > lacks this support. >> > > >> > > This patch extends kexec_file_load system call by adding an extra >> > > argument to this syscall so that an arbitrary number of file descriptors >> > > can be handed out from user space to the kernel. >> > > >> > > See the background [1]. >> > > >> > > Please note that the new interface looks quite similar to the current >> > > system call, but that it won't always mean that it provides the "binary >> > > compatibility." >> > > >> > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html >> > >> > So this design is wrong. The kernel already has the device tree blob, >> > you should not be extracting it from the kernel munging it, and then >> > reinserting it in the kernel if you want signatures and everything to >> > pass. >> >> I don't understand how the kernel signature will be invalidated. >> >> There are some types of boot images that can embed a device tree blob in >> them, but the kernel can also be handed a separate device tree blob from >> firmware, the boot loader, or kexec. This latter case is what we are >> discussing, so we are not talking about modifying an embedded blob in the >> kernel image. >> >> > What x86 does is pass it's equivalent of the device tree blob from one >> > kernel to another directly and behind the scenes. It does not go >> > through userspace for this. >> > >> > Until a persuasive case can be made for going around the kernel and >> > probably adding a feature (like code execution) that can be used to >> > defeat the signature scheme I am going to nack this. >> >> I also don't understand what you mean by code execution. How does passing a >> device tree blob via kexec enables code execution? How can the signature >> scheme be defeated? > > I'm not an expert on DTB, so I can't provide an example of code > execution, but you have already mentioned the /chosen/linux,stdout-path > property. If an attacker redirects the bootloader to an insecure > console, they may get access to the system that would otherwise be > impossible. > > In general, tampering with the hardware inventory of a machine opens up > a security hole, and one must be very cautious which modifications are > allowed. You're giving this power to an (unsigned, hence untrusted) > userspace application; Eric argues that only the kernel should have > this power. At the very least it should be signed. And of course the more signed images we have in different combinations the more easily someone can find a combination that does things the people performing the signing didn't realizing they were allowing. So if we can not add an extra variable into the mix it would be good. Eric
[toc] | [prev] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2016-07-13 00:00 +0200 |
| Message-ID | <rUdSH-2e8-65@gated-at.bofh.it> |
| In reply to | #1441743 |
ebiederm@xmission.com (Eric W. Biederman) writes: > Petr Tesarik <ptesarik@suse.cz> writes: > >> On Tue, 12 Jul 2016 13:25:11 -0300 >> Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote: >> >>> Hi Eric, >>> >>> I'm trying to understand your concerns leading to your nack. I hope you >>> don't mind expanding your thoughts on them a bit. >>> >>> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: >>> > AKASHI Takahiro <takahiro.akashi@linaro.org> writes: >>> > > Device tree blob must be passed to a second kernel on DTB-capable >>> > > archs, like powerpc and arm64, but the current kernel interface >>> > > lacks this support. >>> > > >>> > > This patch extends kexec_file_load system call by adding an extra >>> > > argument to this syscall so that an arbitrary number of file descriptors >>> > > can be handed out from user space to the kernel. >>> > > >>> > > See the background [1]. >>> > > >>> > > Please note that the new interface looks quite similar to the current >>> > > system call, but that it won't always mean that it provides the "binary >>> > > compatibility." >>> > > >>> > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html >>> > >>> > So this design is wrong. The kernel already has the device tree blob, >>> > you should not be extracting it from the kernel munging it, and then >>> > reinserting it in the kernel if you want signatures and everything to >>> > pass. >>> >>> I don't understand how the kernel signature will be invalidated. >>> >>> There are some types of boot images that can embed a device tree blob in >>> them, but the kernel can also be handed a separate device tree blob from >>> firmware, the boot loader, or kexec. This latter case is what we are >>> discussing, so we are not talking about modifying an embedded blob in the >>> kernel image. >>> >>> > What x86 does is pass it's equivalent of the device tree blob from one >>> > kernel to another directly and behind the scenes. It does not go >>> > through userspace for this. >>> > >>> > Until a persuasive case can be made for going around the kernel and >>> > probably adding a feature (like code execution) that can be used to >>> > defeat the signature scheme I am going to nack this. >>> >>> I also don't understand what you mean by code execution. How does passing a >>> device tree blob via kexec enables code execution? How can the signature >>> scheme be defeated? >> >> I'm not an expert on DTB, so I can't provide an example of code >> execution, but you have already mentioned the /chosen/linux,stdout-path >> property. If an attacker redirects the bootloader to an insecure >> console, they may get access to the system that would otherwise be >> impossible. >> >> In general, tampering with the hardware inventory of a machine opens up >> a security hole, and one must be very cautious which modifications are >> allowed. You're giving this power to an (unsigned, hence untrusted) >> userspace application; Eric argues that only the kernel should have >> this power. > > At the very least it should be signed. And of course the more signed > images we have in different combinations the more easily someone can > find a combination that does things the people performing the signing > didn't realizing they were allowing. > > So if we can not add an extra variable into the mix it would be good. But it is even more than that. There was a giant design discussion that lasted months before this code was added on x86. The facts on the ground on x86 are substantially similar to ARM64. So coming up and saying that oh that design sucks and we want to do something completely different to achieve the exact same goals and then not even discussing why the current design can not work in the problem descriptions is inconsiderate. Not taking the time to understand how something works and why and then asking people to explain to them what they are doing wrong is rude. It is a waste of everyones time. I thought I had said something to that effect, but it doesn't look like I did. Apologies for not being clear about that. I have had a lot of that this last little while. Code with big design issues that really should be justified given people are aiming to overturn previous design decisions and not even considering those previous decisions, and I find it quite tiring. Especially when we are dealing with design decisions with a security impact, and peopel want to add code to achieve a security goal I expect people to be paying attention to what effect their changes have on the entire ecosystem. Not just saying the current behavior is inconvinient and using that as a rational for changing things. Eric
[toc] | [prev] | [next] | [standalone]
| From | Petr Tesarik <ptesarik@suse.cz> |
|---|---|
| Date | 2016-07-13 00:00 +0200 |
| Message-ID | <rUdSI-2e8-93@gated-at.bofh.it> |
| In reply to | #1441743 |
On Tue, 12 Jul 2016 16:22:07 -0500
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Petr Tesarik <ptesarik@suse.cz> writes:
>
> > On Tue, 12 Jul 2016 13:25:11 -0300
> > Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote:
>[...]
> >> I also don't understand what you mean by code execution. How does passing a
> >> device tree blob via kexec enables code execution? How can the signature
> >> scheme be defeated?
> >
> > I'm not an expert on DTB, so I can't provide an example of code
> > execution, but you have already mentioned the /chosen/linux,stdout-path
> > property. If an attacker redirects the bootloader to an insecure
> > console, they may get access to the system that would otherwise be
> > impossible.
> >
> > In general, tampering with the hardware inventory of a machine opens up
> > a security hole, and one must be very cautious which modifications are
> > allowed. You're giving this power to an (unsigned, hence untrusted)
> > userspace application; Eric argues that only the kernel should have
> > this power.
>
> At the very least it should be signed. And of course the more signed
> images we have in different combinations the more easily someone can
> find a combination that does things the people performing the signing
> didn't realizing they were allowing.
Exactly. Reminds me of nasty setuid application exploits when one or
more of stdin, stdout and stderr are closed before exec(), so the first
file to be opened gets one of those special file descriptors. Imagine
what happens if the application opens a secret file for reading (now
file descriptor 0), then expects user input on stdin, detects a syntax
error and complains on stderr, including the full input for reference
("%s is not a valid command")...
No one has designed bootloaders to cope with similar unexpected
situations.
> So if we can not add an extra variable into the mix it would be good.
Indeed. Writing boot loaders is difficult enough already. Adding the
same kind of precautions that are necessary to write secure setuid
applications is over the top IMO.
Petr T
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-07-13 00:20 +0200 |
| Message-ID | <rUec2-2Bd-21@gated-at.bofh.it> |
| In reply to | #1441732 |
On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > I'm not an expert on DTB, so I can't provide an example of code > execution, but you have already mentioned the /chosen/linux,stdout-path > property. If an attacker redirects the bootloader to an insecure > console, they may get access to the system that would otherwise be > impossible. I fail to see how kexec connects with the boot loader - the DTB image that's being talked about is one which is passed from the currently running kernel to the to-be-kexec'd kernel. For ARM (and I suspect also ARM64) that's a direct call chain which doesn't involve any boot loader or firmware, and certainly none that would involve the passed DTB image. However, your point is valid as an attacker can redirect the console and/or mounted root on the to-be-kexec'd kernel if they can modify the DTB - and there's a whole host of subtle ways to do that, not necessarily just modification of the kernel command line. > In general, tampering with the hardware inventory of a machine opens up > a security hole, and one must be very cautious which modifications are > allowed. You're giving this power to an (unsigned, hence untrusted) > userspace application; Eric argues that only the kernel should have > this power. Given that, how does crashdump work in this scenario? crashdump works by adding an elfcorehdr=address argument to the crash-booted kernel's command line. If you can add to the kernel command line, you can redirect the console and do all sorts of other stuff like specifying a different filesystem to mount, etc. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Stewart Smith <stewart@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-13 07:10 +0200 |
| Message-ID | <rUkAN-6XH-7@gated-at.bofh.it> |
| In reply to | #1441797 |
Russell King - ARM Linux <linux@armlinux.org.uk> writes: > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> I'm not an expert on DTB, so I can't provide an example of code >> execution, but you have already mentioned the /chosen/linux,stdout-path >> property. If an attacker redirects the bootloader to an insecure >> console, they may get access to the system that would otherwise be >> impossible. > > I fail to see how kexec connects with the boot loader - the DTB image > that's being talked about is one which is passed from the currently > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect > also ARM64) that's a direct call chain which doesn't involve any > boot loader or firmware, and certainly none that would involve the > passed DTB image. For OpenPOWER machines, kexec is the bootloader. Our bootloader is a linux kernel and initramfs with a UI (petitboot) - this means we never have to write a device driver twice: write a kernel one and you're done (for booting from the device and using it in your OS). -- Stewart Smith OPAL Architect, IBM.
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-07-13 09:40 +0200 |
| Message-ID | <rUmVY-8lM-5@gated-at.bofh.it> |
| In reply to | #1441994 |
On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > >> I'm not an expert on DTB, so I can't provide an example of code > >> execution, but you have already mentioned the /chosen/linux,stdout-path > >> property. If an attacker redirects the bootloader to an insecure > >> console, they may get access to the system that would otherwise be > >> impossible. > > > > I fail to see how kexec connects with the boot loader - the DTB image > > that's being talked about is one which is passed from the currently > > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect > > also ARM64) that's a direct call chain which doesn't involve any > > boot loader or firmware, and certainly none that would involve the > > passed DTB image. > > For OpenPOWER machines, kexec is the bootloader. Our bootloader is a > linux kernel and initramfs with a UI (petitboot) - this means we never > have to write a device driver twice: write a kernel one and you're done > (for booting from the device and using it in your OS). I think you misunderstood my point. On ARM, we do not go: kernel (kexec'd from) -> boot loader -> kernel (kexec'd to) but we go: kernel (kexec'd from) -> kernel (kexec'd to) There's no intermediate step involving any bootloader. Hence, my point is that the dtb loaded by kexec is _only_ used by the kernel which is being kexec'd to, not by the bootloader, nor indeed the kernel which it is loaded into. Moreover, if you read the bit that I quoted (which is what I was replying to), you'll notice that it is talking about the DTB loaded by kexec somehow causing the _bootloader_ to be redirected to an alternative console. This point is wholely false on ARM. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Ard Biesheuvel <ard.biesheuvel@linaro.org> |
|---|---|
| Date | 2016-07-13 09:50 +0200 |
| Message-ID | <rUn5E-8pO-7@gated-at.bofh.it> |
| In reply to | #1442116 |
On 13 July 2016 at 09:36, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: >> Russell King - ARM Linux <linux@armlinux.org.uk> writes: >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> >> I'm not an expert on DTB, so I can't provide an example of code >> >> execution, but you have already mentioned the /chosen/linux,stdout-path >> >> property. If an attacker redirects the bootloader to an insecure >> >> console, they may get access to the system that would otherwise be >> >> impossible. >> > >> > I fail to see how kexec connects with the boot loader - the DTB image >> > that's being talked about is one which is passed from the currently >> > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect >> > also ARM64) that's a direct call chain which doesn't involve any >> > boot loader or firmware, and certainly none that would involve the >> > passed DTB image. >> >> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a >> linux kernel and initramfs with a UI (petitboot) - this means we never >> have to write a device driver twice: write a kernel one and you're done >> (for booting from the device and using it in your OS). > > I think you misunderstood my point. > > On ARM, we do not go: > > kernel (kexec'd from) -> boot loader -> kernel (kexec'd to) > > but we go: > > kernel (kexec'd from) -> kernel (kexec'd to) > > There's no intermediate step involving any bootloader. > > Hence, my point is that the dtb loaded by kexec is _only_ used by the > kernel which is being kexec'd to, not by the bootloader, nor indeed > the kernel which it is loaded into. > > Moreover, if you read the bit that I quoted (which is what I was > replying to), you'll notice that it is talking about the DTB loaded > by kexec somehow causing the _bootloader_ to be redirected to an > alternative console. This point is wholely false on ARM. > The particular example may not apply, but the argument that the DTB -as a description of the hardware topology- needs to be signed if the kernel is also signed is valid. We do the same in the UEFI stub, i.e., it normally takes a dtb= argument to allow the DTB to be overridden, but this feature is disabled when Secure Boot is in effect. By the same reasoning, if any kind of kexec kernel image validation is in effect, we should either validate the DTB image as well, or disallow external DTBs and only perform kexec with the kernel's current DTB (the blob it was booted with, not the unflattened data structure)
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-07-13 10:20 +0200 |
| Message-ID | <rUnyG-oj-13@gated-at.bofh.it> |
| In reply to | #1442130 |
On Wed, Jul 13, 2016 at 09:47:56AM +0200, Ard Biesheuvel wrote: > On 13 July 2016 at 09:36, Russell King - ARM Linux > <linux@armlinux.org.uk> wrote: > > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > >> Russell King - ARM Linux <linux@armlinux.org.uk> writes: > >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > >> >> I'm not an expert on DTB, so I can't provide an example of code > >> >> execution, but you have already mentioned the /chosen/linux,stdout-path > >> >> property. If an attacker redirects the bootloader to an insecure > >> >> console, they may get access to the system that would otherwise be > >> >> impossible. > >> > > >> > I fail to see how kexec connects with the boot loader - the DTB image > >> > that's being talked about is one which is passed from the currently > >> > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect > >> > also ARM64) that's a direct call chain which doesn't involve any > >> > boot loader or firmware, and certainly none that would involve the > >> > passed DTB image. > >> > >> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a > >> linux kernel and initramfs with a UI (petitboot) - this means we never > >> have to write a device driver twice: write a kernel one and you're done > >> (for booting from the device and using it in your OS). > > > > I think you misunderstood my point. > > > > On ARM, we do not go: > > > > kernel (kexec'd from) -> boot loader -> kernel (kexec'd to) > > > > but we go: > > > > kernel (kexec'd from) -> kernel (kexec'd to) > > > > There's no intermediate step involving any bootloader. > > > > Hence, my point is that the dtb loaded by kexec is _only_ used by the > > kernel which is being kexec'd to, not by the bootloader, nor indeed > > the kernel which it is loaded into. > > > > Moreover, if you read the bit that I quoted (which is what I was > > replying to), you'll notice that it is talking about the DTB loaded > > by kexec somehow causing the _bootloader_ to be redirected to an > > alternative console. This point is wholely false on ARM. > > > > The particular example may not apply, but the argument that the DTB > -as a description of the hardware topology- needs to be signed if the > kernel is also signed is valid. We do the same in the UEFI stub, i.e., > it normally takes a dtb= argument to allow the DTB to be overridden, > but this feature is disabled when Secure Boot is in effect. By the > same reasoning, if any kind of kexec kernel image validation is in > effect, we should either validate the DTB image as well, or disallow > external DTBs and only perform kexec with the kernel's current DTB > (the blob it was booted with, not the unflattened data structure) *Sigh* yes, I know full well, which is why I said what I said in my _first_ reply: "However, your point is valid as an attacker can redirect the console and/or mounted root on the to-be-kexec'd kernel if they can modify the DTB - and there's a whole host of subtle ways to do that, not necessarily just modification of the kernel command line." and I went on to raise a valid point about the necessity to do that for crashdump, which has been _completely_ ignored. So, I just stopped reading your reply after the first three lines, because we are in fact in agreement... but thanks for trying to waste my time. Please, keep with the overall discussion, and stop replying to a single email as a whole point in isolation to every other email in the thread. And stop bikeshedding, by picking up on the easy stuff but ignoring the more fundamental points, like the crashdump issue I mentioned in my first reply and now this reply. Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Stewart Smith <stewart@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-13 10:30 +0200 |
| Message-ID | <rUnIl-rS-7@gated-at.bofh.it> |
| In reply to | #1442130 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes: > On 13 July 2016 at 09:36, Russell King - ARM Linux > <linux@armlinux.org.uk> wrote: >> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: >>> Russell King - ARM Linux <linux@armlinux.org.uk> writes: >>> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >>> >> I'm not an expert on DTB, so I can't provide an example of code >>> >> execution, but you have already mentioned the /chosen/linux,stdout-path >>> >> property. If an attacker redirects the bootloader to an insecure >>> >> console, they may get access to the system that would otherwise be >>> >> impossible. >>> > >>> > I fail to see how kexec connects with the boot loader - the DTB image >>> > that's being talked about is one which is passed from the currently >>> > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect >>> > also ARM64) that's a direct call chain which doesn't involve any >>> > boot loader or firmware, and certainly none that would involve the >>> > passed DTB image. >>> >>> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a >>> linux kernel and initramfs with a UI (petitboot) - this means we never >>> have to write a device driver twice: write a kernel one and you're done >>> (for booting from the device and using it in your OS). >> >> I think you misunderstood my point. >> >> On ARM, we do not go: >> >> kernel (kexec'd from) -> boot loader -> kernel (kexec'd to) >> >> but we go: >> >> kernel (kexec'd from) -> kernel (kexec'd to) >> >> There's no intermediate step involving any bootloader. >> >> Hence, my point is that the dtb loaded by kexec is _only_ used by the >> kernel which is being kexec'd to, not by the bootloader, nor indeed >> the kernel which it is loaded into. >> >> Moreover, if you read the bit that I quoted (which is what I was >> replying to), you'll notice that it is talking about the DTB loaded >> by kexec somehow causing the _bootloader_ to be redirected to an >> alternative console. This point is wholely false on ARM. >> > > The particular example may not apply, but the argument that the DTB > -as a description of the hardware topology- needs to be signed if the > kernel is also signed is valid. We do the same in the UEFI stub, i.e., > it normally takes a dtb= argument to allow the DTB to be overridden, > but this feature is disabled when Secure Boot is in effect. By the > same reasoning, if any kind of kexec kernel image validation is in > effect, we should either validate the DTB image as well, or disallow > external DTBs and only perform kexec with the kernel's current DTB > (the blob it was booted with, not the unflattened data structure) DTB booted with != current description of hardware We could have had: PCI hotplug, CPU/memory/cache offlined due to hardware error, change in available pstates / CPU frequencies. There is merit in having a signed dtb if you're booting a signed kernel in a secure boot scenario. However, we still need to set up /chosen/ and we still need a way to do something like the offb hack. -- Stewart Smith OPAL Architect, IBM.
[toc] | [prev] | [next] | [standalone]
| From | Stewart Smith <stewart@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-13 10:00 +0200 |
| Message-ID | <rUnfj-8tL-13@gated-at.bofh.it> |
| In reply to | #1442116 |
Russell King - ARM Linux <linux@armlinux.org.uk> writes: > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: >> Russell King - ARM Linux <linux@armlinux.org.uk> writes: >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> >> I'm not an expert on DTB, so I can't provide an example of code >> >> execution, but you have already mentioned the /chosen/linux,stdout-path >> >> property. If an attacker redirects the bootloader to an insecure >> >> console, they may get access to the system that would otherwise be >> >> impossible. >> > >> > I fail to see how kexec connects with the boot loader - the DTB image >> > that's being talked about is one which is passed from the currently >> > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect >> > also ARM64) that's a direct call chain which doesn't involve any >> > boot loader or firmware, and certainly none that would involve the >> > passed DTB image. >> >> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a >> linux kernel and initramfs with a UI (petitboot) - this means we never >> have to write a device driver twice: write a kernel one and you're done >> (for booting from the device and using it in your OS). > > I think you misunderstood my point. > > On ARM, we do not go: > > kernel (kexec'd from) -> boot loader -> kernel (kexec'd to) > > but we go: > > kernel (kexec'd from) -> kernel (kexec'd to) > > There's no intermediate step involving any bootloader. > > Hence, my point is that the dtb loaded by kexec is _only_ used by the > kernel which is being kexec'd to, not by the bootloader, nor indeed > the kernel which it is loaded into. > > Moreover, if you read the bit that I quoted (which is what I was > replying to), you'll notice that it is talking about the DTB loaded > by kexec somehow causing the _bootloader_ to be redirected to an > alternative console. This point is wholely false on ARM. Ahh.. I missed the bootloader bit there. In which case, we're the same on OpenPOWER, there is no intermediate bootloader - in our case we have linux (with kexec) taking on what uboot or grub is typically used for on other platforms. -- Stewart Smith OPAL Architect, IBM.
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-07-13 10:30 +0200 |
| Message-ID | <rUnIl-rS-5@gated-at.bofh.it> |
| In reply to | #1442134 |
On Wed, Jul 13, 2016 at 05:55:33PM +1000, Stewart Smith wrote: > Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > >> Russell King - ARM Linux <linux@armlinux.org.uk> writes: > >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > >> >> I'm not an expert on DTB, so I can't provide an example of code > >> >> execution, but you have already mentioned the /chosen/linux,stdout-path > >> >> property. If an attacker redirects the bootloader to an insecure > >> >> console, they may get access to the system that would otherwise be > >> >> impossible. > >> > > >> > I fail to see how kexec connects with the boot loader - the DTB image > >> > that's being talked about is one which is passed from the currently > >> > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect > >> > also ARM64) that's a direct call chain which doesn't involve any > >> > boot loader or firmware, and certainly none that would involve the > >> > passed DTB image. > >> > >> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a > >> linux kernel and initramfs with a UI (petitboot) - this means we never > >> have to write a device driver twice: write a kernel one and you're done > >> (for booting from the device and using it in your OS). > > > > I think you misunderstood my point. > > > > On ARM, we do not go: > > > > kernel (kexec'd from) -> boot loader -> kernel (kexec'd to) > > > > but we go: > > > > kernel (kexec'd from) -> kernel (kexec'd to) > > > > There's no intermediate step involving any bootloader. > > > > Hence, my point is that the dtb loaded by kexec is _only_ used by the > > kernel which is being kexec'd to, not by the bootloader, nor indeed > > the kernel which it is loaded into. > > > > Moreover, if you read the bit that I quoted (which is what I was > > replying to), you'll notice that it is talking about the DTB loaded > > by kexec somehow causing the _bootloader_ to be redirected to an > > alternative console. This point is wholely false on ARM. > > Ahh.. I missed the bootloader bit there. > > In which case, we're the same on OpenPOWER, there is no intermediate > bootloader - in our case we have linux (with kexec) taking on what uboot > or grub is typically used for on other platforms. 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? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Dave Young <dyoung@redhat.com> |
|---|---|
| Date | 2016-07-13 10:40 +0200 |
| Message-ID | <rUnS2-vb-11@gated-at.bofh.it> |
| In reply to | #1442163 |
[snip] > 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? The kexec_file_load syscall was introduced for secure boot in the first place. In case UEFI secure boot the signature verification chain only covers kernel mode binaries. I think there is such problem in both normal boot and kexec boot. Thanks Dave
[toc] | [prev] | [next] | [standalone]
| From | Petr Tesarik <ptesarik@suse.cz> |
|---|---|
| Date | 2016-07-13 11:00 +0200 |
| Message-ID | <rUobn-D9-1@gated-at.bofh.it> |
| In reply to | #1442163 |
On Wed, 13 Jul 2016 09:26:39 +0100 Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Wed, Jul 13, 2016 at 05:55:33PM +1000, Stewart Smith wrote: > > Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > > >> Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > > >> >> I'm not an expert on DTB, so I can't provide an example of code > > >> >> execution, but you have already mentioned the /chosen/linux,stdout-path > > >> >> property. If an attacker redirects the bootloader to an insecure > > >> >> console, they may get access to the system that would otherwise be > > >> >> impossible. > > >> > > > >> > I fail to see how kexec connects with the boot loader - the DTB image > > >> > that's being talked about is one which is passed from the currently > > >> > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect > > >> > also ARM64) that's a direct call chain which doesn't involve any > > >> > boot loader or firmware, and certainly none that would involve the > > >> > passed DTB image. > > >> > > >> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a > > >> linux kernel and initramfs with a UI (petitboot) - this means we never > > >> have to write a device driver twice: write a kernel one and you're done > > >> (for booting from the device and using it in your OS). > > > > > > I think you misunderstood my point. > > > > > > On ARM, we do not go: > > > > > > kernel (kexec'd from) -> boot loader -> kernel (kexec'd to) > > > > > > but we go: > > > > > > kernel (kexec'd from) -> kernel (kexec'd to) > > > > > > There's no intermediate step involving any bootloader. > > > > > > Hence, my point is that the dtb loaded by kexec is _only_ used by the > > > kernel which is being kexec'd to, not by the bootloader, nor indeed > > > the kernel which it is loaded into. > > > > > > Moreover, if you read the bit that I quoted (which is what I was > > > replying to), you'll notice that it is talking about the DTB loaded > > > by kexec somehow causing the _bootloader_ to be redirected to an > > > alternative console. This point is wholely false on ARM. > > > > Ahh.. I missed the bootloader bit there. > > > > In which case, we're the same on OpenPOWER, there is no intermediate > > bootloader - in our case we have linux (with kexec) taking on what uboot > > or grub is typically used for on other platforms. > > 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? This is a valid point. If there are kernel options that can be misused to defeat the purpose of UEFI SecureBoot, then we're in trouble. Generally, the Linux kernel should treat the command line as untrusted source. My point is that modifying the DTB opens a completely new attack vector. And the goal is not extending the attack surface (because there are holes in it already), but reducing the attack surface (e.g. by limiting available kernel command line options). Petr T
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-13 15:10 +0200 |
| Message-ID | <rUs5l-3uO-35@gated-at.bofh.it> |
| In reply to | #1442163 |
On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 13, 2016 at 05:55:33PM +1000, Stewart Smith wrote: > > Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: > > >> Russell King - ARM Linux <linux@armlinux.org.uk> writes: > > >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > > >> >> I'm not an expert on DTB, so I can't provide an example of code > > >> >> execution, but you have already mentioned the /chosen/linux,stdout-path > > >> >> property. If an attacker redirects the bootloader to an insecure > > >> >> console, they may get access to the system that would otherwise be > > >> >> impossible. > > >> > > > >> > I fail to see how kexec connects with the boot loader - the DTB image > > >> > that's being talked about is one which is passed from the currently > > >> > running kernel to the to-be-kexec'd kernel. For ARM (and I suspect > > >> > also ARM64) that's a direct call chain which doesn't involve any > > >> > boot loader or firmware, and certainly none that would involve the > > >> > passed DTB image. > > >> > > >> For OpenPOWER machines, kexec is the bootloader. Our bootloader is a > > >> linux kernel and initramfs with a UI (petitboot) - this means we never > > >> have to write a device driver twice: write a kernel one and you're done > > >> (for booting from the device and using it in your OS). > > > > > > I think you misunderstood my point. > > > > > > On ARM, we do not go: > > > > > > kernel (kexec'd from) -> boot loader -> kernel (kexec'd to) > > > > > > but we go: > > > > > > kernel (kexec'd from) -> kernel (kexec'd to) > > > > > > There's no intermediate step involving any bootloader. > > > > > > Hence, my point is that the dtb loaded by kexec is _only_ used by the > > > kernel which is being kexec'd to, not by the bootloader, nor indeed > > > the kernel which it is loaded into. > > > > > > Moreover, if you read the bit that I quoted (which is what I was > > > replying to), you'll notice that it is talking about the DTB loaded > > > by kexec somehow causing the _bootloader_ to be redirected to an > > > alternative console. This point is wholely false on ARM. > > > > Ahh.. I missed the bootloader bit there. > > > > In which case, we're the same on OpenPOWER, there is no intermediate > > bootloader - in our case we have linux (with kexec) taking on what uboot > > or grub is typically used for on other platforms. > > 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. So it sounds like different class of security problems which you are referring to and not necessarily covered by secureboot or signed kernel. Vivek
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-07-13 19:50 +0200 |
| Message-ID | <rUwsh-6gf-7@gated-at.bofh.it> |
| In reply to | #1442439 |
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. > > 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 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. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-13 20:30 +0200 |
| Message-ID | <rUx50-6Li-25@gated-at.bofh.it> |
| In reply to | #1442721 |
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. > > > > 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 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. > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Balbir Singh <bsingharora@gmail.com> |
|---|---|
| Date | 2016-07-18 14:50 +0200 |
| Message-ID | <rWg9J-6cJ-77@gated-at.bofh.it> |
| In reply to | #1442746 |
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
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.kernel
csiph-web