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 1 of 4 [1] 2 3 4 Next page →
| From | AKASHI Takahiro <takahiro.akashi@linaro.org> |
|---|---|
| Date | 2016-07-12 03:40 +0200 |
| Subject | [RFC 0/3] extend kexec_file_load system call |
| Message-ID | <rTUQ1-6xe-5@gated-at.bofh.it> |
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 AKASHI Takahiro (3): syscall: add kexec_file_load to generic unistd.h kexec: add dtb info to struct kimage kexec: extend kexec_file_load system call include/linux/fs.h | 1 + include/linux/kexec.h | 5 +++- include/linux/syscalls.h | 4 ++- include/uapi/asm-generic/unistd.h | 8 ++++- include/uapi/linux/kexec.h | 17 +++++++++++ kernel/kexec_file.c | 62 ++++++++++++++++++++++++++++++++++----- 6 files changed, 87 insertions(+), 10 deletions(-) -- 2.9.0
[toc] | [next] | [standalone]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2016-07-12 15:40 +0200 |
| Message-ID | <rU64O-5xF-27@gated-at.bofh.it> |
| In reply to | #1441013 |
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. 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. Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com> I am happy to see support for other architectures, but for the sake of not moving some code in the kernel let's not build an attackable infrastructure. Eric
[toc] | [prev] | [next] | [standalone]
| From | Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-12 16:00 +0200 |
| Message-ID | <rU6oa-5Gg-33@gated-at.bofh.it> |
| In reply to | #1441358 |
Hello Eric, 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. > > 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. There are situations where userspace needs to change things in the device tree to be used by the next kernel. For example, Petitboot (the boot loader used in OpenPOWER machines) is a userspace application running in an intermediary Linux instance and uses kexec to load the target OS. It has to modify the device tree that will be used by the next kernel so that the next kernel uses the same console that petitboot was configured to use (i.e., set the /chosen/linux,stdout-path property). It also modifies the device tree to allow the kernel to inherit Petitboot's Openfirmware framebuffer. -- []'s Thiago Jung Bauermann IBM Linux Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-12 16:10 +0200 |
| Message-ID | <rU6xQ-5Z5-13@gated-at.bofh.it> |
| In reply to | #1441373 |
On Tue, Jul 12, 2016 at 10:58:09AM -0300, Thiago Jung Bauermann wrote: > Hello Eric, > > 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. > > > > 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. > > There are situations where userspace needs to change things in the device > tree to be used by the next kernel. > > For example, Petitboot (the boot loader used in OpenPOWER machines) is a > userspace application running in an intermediary Linux instance and uses > kexec to load the target OS. It has to modify the device tree that will be > used by the next kernel so that the next kernel uses the same console that > petitboot was configured to use (i.e., set the /chosen/linux,stdout-path > property). It also modifies the device tree to allow the kernel to inherit > Petitboot's Openfirmware framebuffer. Can some of this be done with the help of kernel command line options for second kernel? Vivek
[toc] | [prev] | [next] | [standalone]
| From | Stewart Smith <stewart@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-13 01:50 +0200 |
| Message-ID | <rUfB7-3og-7@gated-at.bofh.it> |
| In reply to | #1441379 |
Vivek Goyal <vgoyal@redhat.com> writes: > On Tue, Jul 12, 2016 at 10:58:09AM -0300, Thiago Jung Bauermann wrote: >> Hello Eric, >> >> 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. >> > >> > 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. >> >> There are situations where userspace needs to change things in the device >> tree to be used by the next kernel. >> >> For example, Petitboot (the boot loader used in OpenPOWER machines) is a >> userspace application running in an intermediary Linux instance and uses >> kexec to load the target OS. It has to modify the device tree that will be >> used by the next kernel so that the next kernel uses the same console that >> petitboot was configured to use (i.e., set the /chosen/linux,stdout-path >> property). It also modifies the device tree to allow the kernel to inherit >> Petitboot's Openfirmware framebuffer. > > Can some of this be done with the help of kernel command line options for > second kernel? how would this be any more secure? Passing in an address for a framebuffer via command line option means you could scribble over any bit of memory, which is the same kind of damage you could do by modifying the device tree. -- Stewart Smith OPAL Architect, IBM.
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-13 15:30 +0200 |
| Message-ID | <rUsoF-3Co-11@gated-at.bofh.it> |
| In reply to | #1441920 |
On Wed, Jul 13, 2016 at 09:45:22AM +1000, Stewart Smith wrote: > Vivek Goyal <vgoyal@redhat.com> writes: > > On Tue, Jul 12, 2016 at 10:58:09AM -0300, Thiago Jung Bauermann wrote: > >> Hello Eric, > >> > >> 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. > >> > > >> > 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. > >> > >> There are situations where userspace needs to change things in the device > >> tree to be used by the next kernel. > >> > >> For example, Petitboot (the boot loader used in OpenPOWER machines) is a > >> userspace application running in an intermediary Linux instance and uses > >> kexec to load the target OS. It has to modify the device tree that will be > >> used by the next kernel so that the next kernel uses the same console that > >> petitboot was configured to use (i.e., set the /chosen/linux,stdout-path > >> property). It also modifies the device tree to allow the kernel to inherit > >> Petitboot's Openfirmware framebuffer. > > > > Can some of this be done with the help of kernel command line options for > > second kernel? > > how would this be any more secure? > > Passing in an address for a framebuffer via command line option means > you could scribble over any bit of memory, which is the same kind of > damage you could do by modifying the device tree. It is not necessarily safer but works with given framework and we don't have to modify existing system call. Also it will allow you to pass in only one thing at a time instead of allowing passing in new unsigned DTB, which can potentially do lot more. Vivek
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-07-12 16:10 +0200 |
| Message-ID | <rU6xR-5Z5-61@gated-at.bofh.it> |
| In reply to | #1441358 |
On Tuesday, July 12, 2016 8:25:48 AM CEST Eric W. Biederman wrote: > 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. > > 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. > > Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com> > > I am happy to see support for other architectures, but for the sake of > not moving some code in the kernel let's not build an attackable > infrastructure. > For historic context, the flattened devicetree format that we now use to pass data about the system from boot loader to kernel was initially introduced specifically for the purpose of enabling kexec: On Open Firmware, the DT is extracted from running firmware and copied into dynamically allocated data structures. After a kexec, the runtime interface to the firmware is not available, so the flattened DT format was created as a way to pass the same data in a binary blob to the new kernel in a format that can be read from the kernel by walking the directories in /proc/device-tree/*. There are a couple of reasons for modifying the devicetree: - For kboot/petitboot, you can have a kernel that is not booted through DT at all but hardwired to a particular machine, and that passes a DT for the entire hardware to the kernel that you actually want to run. - for kdump, you need to tell the new kernel about the modified location of the memory, so the dump kernel doesn't overwrite the contents it wants to dump - we typically ship devicetree sources for embedded machines with the kernel sources. As more hardware of the system gets enabled, the devicetree gains extra nodes and properties that describe the hardware more completely, so we need to use the latest DT blob to use all the drivers - in some cases, kernels will fail to boot at all with an older version of the DT, or fail to use the devices that were working on the earlier kernel. This is usually considered a bug, but it's not rare - In some cases, the kernel can update its DT at runtime, and the new settings are expected to be available in the new kernel too, though there are cases where you actually don't want the modified contents. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-12 16:20 +0200 |
| Message-ID | <rU6Hv-62T-7@gated-at.bofh.it> |
| In reply to | #1441385 |
On Tue, Jul 12, 2016 at 04:02:46PM +0200, Arnd Bergmann wrote: > On Tuesday, July 12, 2016 8:25:48 AM CEST Eric W. Biederman wrote: > > 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. > > > > 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. > > > > Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com> > > > > I am happy to see support for other architectures, but for the sake of > > not moving some code in the kernel let's not build an attackable > > infrastructure. > > > > For historic context, the flattened devicetree format that we now use > to pass data about the system from boot loader to kernel was initially > introduced specifically for the purpose of enabling kexec: > > On Open Firmware, the DT is extracted from running firmware and copied > into dynamically allocated data structures. After a kexec, the runtime > interface to the firmware is not available, so the flattened DT format > was created as a way to pass the same data in a binary blob to the new > kernel in a format that can be read from the kernel by walking the > directories in /proc/device-tree/*. So this DT is available inside kernel and running kernel can still retrieve it and pass it to second kernel? > > There are a couple of reasons for modifying the devicetree: > > - For kboot/petitboot, you can have a kernel that is not booted through > DT at all but hardwired to a particular machine, and that passes > a DT for the entire hardware to the kernel that you actually want to > run. > > - for kdump, you need to tell the new kernel about the modified location > of the memory, so the dump kernel doesn't overwrite the contents > it wants to dump In x86 we do this with the help of kernel command line options. > > - we typically ship devicetree sources for embedded machines with the > kernel sources. As more hardware of the system gets enabled, the > devicetree gains extra nodes and properties that describe the hardware > more completely, so we need to use the latest DT blob to use all > the drivers > > - in some cases, kernels will fail to boot at all with an older version > of the DT, or fail to use the devices that were working on the > earlier kernel. This is usually considered a bug, but it's not rare > > - In some cases, the kernel can update its DT at runtime, and the new > settings are expected to be available in the new kernel too, though > there are cases where you actually don't want the modified contents. I am assuming that modified DT and unmodifed one both are accessible to kernel. And if user space can make decisions which modfied fields to use for new kernels and which ones not, then same can be done in kernel too? Vivek > > Arnd
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-07-12 16:30 +0200 |
| Message-ID | <rU6Rd-66R-59@gated-at.bofh.it> |
| In reply to | #1441394 |
On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > On Open Firmware, the DT is extracted from running firmware and copied > > into dynamically allocated data structures. After a kexec, the runtime > > interface to the firmware is not available, so the flattened DT format > > was created as a way to pass the same data in a binary blob to the new > > kernel in a format that can be read from the kernel by walking the > > directories in /proc/device-tree/*. > > So this DT is available inside kernel and running kernel can still > retrieve it and pass it to second kernel? The kernel only uses the flattened DT blob at boot time and converts it into the runtime data structures (struct device_node). The original dtb is typically overwritten later. > > - we typically ship devicetree sources for embedded machines with the > > kernel sources. As more hardware of the system gets enabled, the > > devicetree gains extra nodes and properties that describe the hardware > > more completely, so we need to use the latest DT blob to use all > > the drivers > > > > - in some cases, kernels will fail to boot at all with an older version > > of the DT, or fail to use the devices that were working on the > > earlier kernel. This is usually considered a bug, but it's not rare > > > > - In some cases, the kernel can update its DT at runtime, and the new > > settings are expected to be available in the new kernel too, though > > there are cases where you actually don't want the modified contents. > > I am assuming that modified DT and unmodifed one both are accessible to > kernel. And if user space can make decisions which modfied fields to use > for new kernels and which ones not, then same can be done in kernel too? The unmodified DT can typically be found on disk next to the kernel binary. The option you have is to either read it from /proc/devicetree or to read it from from /boot/*.dtb. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Mark Rutland <mark.rutland@arm.com> |
|---|---|
| Date | 2016-07-12 17:00 +0200 |
| Message-ID | <rU7ke-6jl-19@gated-at.bofh.it> |
| In reply to | #1441416 |
On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > into dynamically allocated data structures. After a kexec, the runtime > > > interface to the firmware is not available, so the flattened DT format > > > was created as a way to pass the same data in a binary blob to the new > > > kernel in a format that can be read from the kernel by walking the > > > directories in /proc/device-tree/*. > > > > So this DT is available inside kernel and running kernel can still > > retrieve it and pass it to second kernel? > > The kernel only uses the flattened DT blob at boot time and converts > it into the runtime data structures (struct device_node). The original > dtb is typically overwritten later. On arm64 we deliberately preserved the DTB, so we can take that and build a new DTB from that kernel-side. > > > - we typically ship devicetree sources for embedded machines with the > > > kernel sources. As more hardware of the system gets enabled, the > > > devicetree gains extra nodes and properties that describe the hardware > > > more completely, so we need to use the latest DT blob to use all > > > the drivers > > > > > > - in some cases, kernels will fail to boot at all with an older version > > > of the DT, or fail to use the devices that were working on the > > > earlier kernel. This is usually considered a bug, but it's not rare > > > > > > - In some cases, the kernel can update its DT at runtime, and the new > > > settings are expected to be available in the new kernel too, though > > > there are cases where you actually don't want the modified contents. > > > > I am assuming that modified DT and unmodifed one both are accessible to > > kernel. And if user space can make decisions which modfied fields to use > > for new kernels and which ones not, then same can be done in kernel too? > > The unmodified DT can typically be found on disk next to the kernel binary. > The option you have is to either read it from /proc/devicetree or to > read it from from /boot/*.dtb. /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived from the raw DTB (which is exposed at /sys/firmware/fdt). The blob that was handed to the kernel at boot time is exposed at /sys/firmware/fdt. Thanks, Mark.
[toc] | [prev] | [next] | [standalone]
| From | Dave Young <dyoung@redhat.com> |
|---|---|
| Date | 2016-07-13 04:40 +0200 |
| Message-ID | <rUifD-5fa-1@gated-at.bofh.it> |
| In reply to | #1441472 |
On 07/12/16 at 03:50pm, Mark Rutland wrote: > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > > into dynamically allocated data structures. After a kexec, the runtime > > > > interface to the firmware is not available, so the flattened DT format > > > > was created as a way to pass the same data in a binary blob to the new > > > > kernel in a format that can be read from the kernel by walking the > > > > directories in /proc/device-tree/*. > > > > > > So this DT is available inside kernel and running kernel can still > > > retrieve it and pass it to second kernel? > > > > The kernel only uses the flattened DT blob at boot time and converts > > it into the runtime data structures (struct device_node). The original > > dtb is typically overwritten later. > > On arm64 we deliberately preserved the DTB, so we can take that and > build a new DTB from that kernel-side. > > > > > - we typically ship devicetree sources for embedded machines with the > > > > kernel sources. As more hardware of the system gets enabled, the > > > > devicetree gains extra nodes and properties that describe the hardware > > > > more completely, so we need to use the latest DT blob to use all > > > > the drivers > > > > > > > > - in some cases, kernels will fail to boot at all with an older version > > > > of the DT, or fail to use the devices that were working on the > > > > earlier kernel. This is usually considered a bug, but it's not rare > > > > > > > > - In some cases, the kernel can update its DT at runtime, and the new > > > > settings are expected to be available in the new kernel too, though > > > > there are cases where you actually don't want the modified contents. > > > > > > I am assuming that modified DT and unmodifed one both are accessible to > > > kernel. And if user space can make decisions which modfied fields to use > > > for new kernels and which ones not, then same can be done in kernel too? > > > > The unmodified DT can typically be found on disk next to the kernel binary. > > The option you have is to either read it from /proc/devicetree or to > > read it from from /boot/*.dtb. > > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived > from the raw DTB (which is exposed at /sys/firmware/fdt). > > The blob that was handed to the kernel at boot time is exposed at > /sys/firmware/fdt. I believe the blob can be read and passed to kexec kernel in kernel code without the extra fd. 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. From my understanding it is reasonable but yes I think we should think carefully about the design. Thanks Dave > Thanks, > Mark. > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-07-13 10:10 +0200 |
| Message-ID | <rUnp0-kO-17@gated-at.bofh.it> |
| In reply to | #1441972 |
On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived > > from the raw DTB (which is exposed at /sys/firmware/fdt). > > > > The blob that was handed to the kernel at boot time is exposed at > > /sys/firmware/fdt. > > I believe the blob can be read and passed to kexec kernel in kernel code without > the extra fd. > > 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. From my understanding > it is reasonable but yes I think we should think carefully about the design. Ok, I can see four interesting use cases here: - Using the dtb that the kernel has saved at boot time. Ideally this should not require an additional step of signing it, since the running kernel already trusts it. - A dtb blob from the file system that was produced along with the kernel image. If we require a signature on the kernel, the the same requirement should be made on the dtb. Whoever signs the kernel can also sign the dtb. The tricky part here is the kernel command line that is part of the dtb and that may need to be modified. - Modifying the dtb at for any of the reasons I listed: This should always be possible when we do not use secure boot, just like booting an unsigned kernel is. - kboot/petitboot with all of the user space being part of the trusted boot chain: it would be good to allow these to modify the dtb as needed without breaking the trust chain, just like we allow grub or u-boot to modify the dtb before passing it to the kernel. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Stewart Smith <stewart@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-13 10:30 +0200 |
| Message-ID | <rUnIl-rS-17@gated-at.bofh.it> |
| In reply to | #1442149 |
Arnd Bergmann <arnd@arndb.de> writes: > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: >> On 07/12/16 at 03:50pm, Mark Rutland wrote: >> > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: >> > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: >> > >> > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived >> > from the raw DTB (which is exposed at /sys/firmware/fdt). >> > >> > The blob that was handed to the kernel at boot time is exposed at >> > /sys/firmware/fdt. >> >> I believe the blob can be read and passed to kexec kernel in kernel code without >> the extra fd. >> >> 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. From my understanding >> it is reasonable but yes I think we should think carefully about the design. > > Ok, I can see four interesting use cases here: > > - Using the dtb that the kernel has saved at boot time. Ideally this should not > require an additional step of signing it, since the running kernel already > trusts it. - using current view of the hardware, flattened into a new dtb. This should already be trusted, as it's what we're running now (boot + runtime changes) -- Stewart Smith OPAL Architect, IBM.
[toc] | [prev] | [next] | [standalone]
| From | Mark Rutland <mark.rutland@arm.com> |
|---|---|
| Date | 2016-07-13 11:50 +0200 |
| Message-ID | <rUoXL-1bB-7@gated-at.bofh.it> |
| In reply to | #1442149 |
On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived > > > from the raw DTB (which is exposed at /sys/firmware/fdt). > > > > > > The blob that was handed to the kernel at boot time is exposed at > > > /sys/firmware/fdt. > > > > I believe the blob can be read and passed to kexec kernel in kernel code without > > the extra fd. > > > > 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. From my understanding > > it is reasonable but yes I think we should think carefully about the design. > > Ok, I can see four interesting use cases here: > > - Using the dtb that the kernel has saved at boot time. Ideally this should not > require an additional step of signing it, since the running kernel already > trusts it. We have sufficient information from the existing kexec_file_load syscall prototype to do this in-kernel. > - A dtb blob from the file system that was produced along with the kernel image. > If we require a signature on the kernel, the the same requirement should be > made on the dtb. Whoever signs the kernel can also sign the dtb. > The tricky part here is the kernel command line that is part of the dtb > and that may need to be modified. I suspect that for this case, following the example of the existing sycall, we'd allow the kernel to modify bootargs and initrd properties after verfiying the signature of the DTB. The big question is whether this is a realistic case on a secure boot system. > - Modifying the dtb at for any of the reasons I listed: This should always > be possible when we do not use secure boot, just like booting an unsigned > kernel is. This is possible with the existing kexec_load syscall, for the non secure boot case. > - kboot/petitboot with all of the user space being part of the trusted boot > chain: it would be good to allow these to modify the dtb as needed without > breaking the trust chain, just like we allow grub or u-boot to modify the dtb > before passing it to the kernel. It depends on *what* we need to modify here. We can modify the bootargs and initrd properties as part of the kexec_file_load syscall, so what else would we want to alter? Thanks, Mark.
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-07-13 15:20 +0200 |
| Message-ID | <rUsf0-3yv-15@gated-at.bofh.it> |
| In reply to | #1442269 |
On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > > On Wednesday, July 13, 2016 10:36:14 AM CEST Dave Young wrote: > > > On 07/12/16 at 03:50pm, Mark Rutland wrote: > > > > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > > > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > > > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived > > > > from the raw DTB (which is exposed at /sys/firmware/fdt). > > > > > > > > The blob that was handed to the kernel at boot time is exposed at > > > > /sys/firmware/fdt. > > > > > > I believe the blob can be read and passed to kexec kernel in kernel code without > > > the extra fd. > > > > > > 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. From my understanding > > > it is reasonable but yes I think we should think carefully about the design. > > > > Ok, I can see four interesting use cases here: > > > > - Using the dtb that the kernel has saved at boot time. Ideally this should not > > require an additional step of signing it, since the running kernel already > > trusts it. > > We have sufficient information from the existing kexec_file_load syscall > prototype to do this in-kernel. Ok. > > - A dtb blob from the file system that was produced along with the kernel image. > > If we require a signature on the kernel, the the same requirement should be > > made on the dtb. Whoever signs the kernel can also sign the dtb. > > The tricky part here is the kernel command line that is part of the dtb > > and that may need to be modified. > > I suspect that for this case, following the example of the existing > sycall, we'd allow the kernel to modify bootargs and initrd properties > after verfiying the signature of the DTB. Makes sense. > The big question is whether this is a realistic case on a secure boot > system. What does x86 do here? I assume changes to the command line are also limited. > > - Modifying the dtb at for any of the reasons I listed: This should always > > be possible when we do not use secure boot, just like booting an unsigned > > kernel is. > > This is possible with the existing kexec_load syscall, for the non > secure boot case. Ok, let's skip that then. > > - kboot/petitboot with all of the user space being part of the trusted boot > > chain: it would be good to allow these to modify the dtb as needed without > > breaking the trust chain, just like we allow grub or u-boot to modify the dtb > > before passing it to the kernel. > > It depends on *what* we need to modify here. We can modify the bootargs > and initrd properties as part of the kexec_file_load syscall, so what > else would we want to alter? I guess petitboot can also just use kexec_load() instead of kexec_file_load(), as long as the initramfs containing petitboot is trusted by the kernel. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-13 20:50 +0200 |
| Message-ID | <rUxom-6SS-21@gated-at.bofh.it> |
| In reply to | #1442444 |
Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > > On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > > > - kboot/petitboot with all of the user space being part of the trusted > > > boot> > > > > chain: it would be good to allow these to modify the dtb as needed > > > without breaking the trust chain, just like we allow grub or u-boot > > > to modify the dtb before passing it to the kernel. > > > > It depends on *what* we need to modify here. We can modify the bootargs > > and initrd properties as part of the kexec_file_load syscall, so what > > else would we want to alter? > > I guess petitboot can also just use kexec_load() instead of > kexec_file_load(), as long as the initramfs containing petitboot is > trusted by the kernel. For secure boot, Petitboot needs to use kexec_file_load, because of the following two features which the system call enables: 1. only allow loading of signed kernels. 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel command line and other boot inputs for the Integrity Measurement Architecture subsystem. Those can't be done with kexec_load. As for what we need to modify, Petitboot does the following modifications to the DTB: 1. Set /chosen/linux,stdout-path based on which console is being used to interact with it, as Stewart mentioned in another email. 2. Set display properties on /pciex@n/.../vga@0 in machines with an OpenFirmware framebuffer. -- []'s Thiago Jung Bauermann IBM Linux Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-07-13 22:10 +0200 |
| Message-ID | <rUyDM-7RI-17@gated-at.bofh.it> |
| In reply to | #1442767 |
On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > > On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > > > On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > > > > - kboot/petitboot with all of the user space being part of the trusted > > > > boot> > > > > > chain: it would be good to allow these to modify the dtb as needed > > > > without breaking the trust chain, just like we allow grub or u-boot > > > > to modify the dtb before passing it to the kernel. > > > > > > It depends on *what* we need to modify here. We can modify the bootargs > > > and initrd properties as part of the kexec_file_load syscall, so what > > > else would we want to alter? > > > > I guess petitboot can also just use kexec_load() instead of > > kexec_file_load(), as long as the initramfs containing petitboot is > > trusted by the kernel. > > For secure boot, Petitboot needs to use kexec_file_load, because of the > following two features which the system call enables: > > 1. only allow loading of signed kernels. > 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel > command line and other boot inputs for the Integrity Measurement > Architecture subsystem. > > Those can't be done with kexec_load. Can't petitboot do both of these in user space? Arnd
[toc] | [prev] | [next] | [standalone]
| From | Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-14 04:20 +0200 |
| Message-ID | <rUEpQ-3ke-5@gated-at.bofh.it> |
| In reply to | #1442802 |
Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann: > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > > > On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > > > > On Wed, Jul 13, 2016 at 10:01:33AM +0200, Arnd Bergmann wrote: > > > > > - kboot/petitboot with all of the user space being part of the > > > > > trusted > > > > > boot> > > > > > > > > > > > chain: it would be good to allow these to modify the dtb as > > > > > needed > > > > > without breaking the trust chain, just like we allow grub or > > > > > u-boot > > > > > to modify the dtb before passing it to the kernel. > > > > > > > > It depends on *what* we need to modify here. We can modify the > > > > bootargs > > > > and initrd properties as part of the kexec_file_load syscall, so > > > > what > > > > else would we want to alter? > > > > > > I guess petitboot can also just use kexec_load() instead of > > > kexec_file_load(), as long as the initramfs containing petitboot is > > > trusted by the kernel. > > > > For secure boot, Petitboot needs to use kexec_file_load, because of the > > following two features which the system call enables: > > > > 1. only allow loading of signed kernels. > > 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel > > > > command line and other boot inputs for the Integrity Measurement > > Architecture subsystem. > > > > Those can't be done with kexec_load. > > Can't petitboot do both of these in user space? To be honest I'm not sure if it *can't* be done from userspace but if you do it from the kernel you can guarantee that any kernel image that is loaded gets verified and measured. Whereas if you verify and measure the kernel in userspace then if there's a vulnerability in the system which allows an attacker to upload their own binary, then they can use kexec_load directly and bypass the verification and measurement. So it's a more resilient design. -- []'s Thiago Jung Bauermann IBM Linux Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-07-14 10:40 +0200 |
| Message-ID | <rUKlA-7jX-47@gated-at.bofh.it> |
| In reply to | #1443003 |
On Wednesday, July 13, 2016 11:18:04 PM CEST Thiago Jung Bauermann wrote: > Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann: > > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > > > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > > > > > > For secure boot, Petitboot needs to use kexec_file_load, because of the > > > following two features which the system call enables: > > > > > > 1. only allow loading of signed kernels. > > > 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel > > > > > > command line and other boot inputs for the Integrity Measurement > > > Architecture subsystem. > > > > > > Those can't be done with kexec_load. > > > > Can't petitboot do both of these in user space? > > To be honest I'm not sure if it *can't* be done from userspace but if you do > it from the kernel you can guarantee that any kernel image that is loaded > gets verified and measured. > > Whereas if you verify and measure the kernel in userspace then if there's a > vulnerability in the system which allows an attacker to upload their own > binary, then they can use kexec_load directly and bypass the verification > and measurement. > > So it's a more resilient design. Right, but the question remains whether this helps while you allow the boot loader to modify the dtb. If an attacker gets in and cannot modify the kernel or initid but can modify the DT, a successful attack would be a bit harder than having a modified kernel, but you may still need to treat the system as compromised. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-15 03:50 +0200 |
| Message-ID | <rV0ql-uG-9@gated-at.bofh.it> |
| In reply to | #1443240 |
Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann: > On Wednesday, July 13, 2016 11:18:04 PM CEST Thiago Jung Bauermann wrote: > > Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann: > > > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote: > > > > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann: > > > > > > > > For secure boot, Petitboot needs to use kexec_file_load, because of > > > > the > > > > following two features which the system call enables: > > > > > > > > 1. only allow loading of signed kernels. > > > > 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel > > > > > > > > command line and other boot inputs for the Integrity Measurement > > > > Architecture subsystem. > > > > > > > > Those can't be done with kexec_load. > > > > > > Can't petitboot do both of these in user space? > > > > To be honest I'm not sure if it *can't* be done from userspace but if > > you do it from the kernel you can guarantee that any kernel image that > > is loaded gets verified and measured. > > > > Whereas if you verify and measure the kernel in userspace then if > > there's a vulnerability in the system which allows an attacker to > > upload their own binary, then they can use kexec_load directly and > > bypass the verification and measurement. > > > > So it's a more resilient design. > > Right, but the question remains whether this helps while you allow the > boot loader to modify the dtb. If an attacker gets in and cannot modify > the kernel or initid but can modify the DT, a successful attack would > be a bit harder than having a modified kernel, but you may still need > to treat the system as compromised. Yes, and the same question also remains regarding the kernel command line. We can have the kernel perform sanity checks on the device tree, just as the kernel needs to sanity check the command line. There's the point that was raised about not wanting to increase the attack surface, and that's a valid point. But at least in the way Petitboot works today, it needs to modify the device tree and pass it to the kernel. One thing that is unavoidable to come from userspace is /chosen/linux,stdout-path, because it's Petitboot that knows from which console the user is interacting with. The other modification to set properties in vga@0 can be done in the kernel. Given that on DTB-based systems /chosen is an important and established way to pass information to the operating system being booted, I'd like to suggest the following, then: Extend the syscall as shown in this RFC from Takahiro AKASHI, but instead of accepting a complete DTB from userspace, the syscall would accept a DTB containing only a /chosen node. If the DTB contains any other node, the syscall fails with EINVAL. The kernel can then add the properties in /chosen to the device tree that it will pass to the next kernel. What do you think? -- []'s Thiago Jung Bauermann IBM Linux Technology Center
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.kernel
csiph-web