[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <87twfunneg.fsf@linux.vnet.ibm.com>
Date: Wed, 13 Jul 2016 14:59:51 +1000
From: Stewart Smith <stewart@...ux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@...linux.org.uk>,
Petr Tesarik <ptesarik@...e.cz>
Cc: linux-arm-kernel@...ts.infradead.org, bhe@...hat.com,
arnd@...db.de, linuxppc-dev@...ts.ozlabs.org,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
AKASHI Takahiro <takahiro.akashi@...aro.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Thiago Jung Bauermann <bauerman@...ux.vnet.ibm.com>,
dyoung@...hat.com, vgoyal@...hat.com
Subject: Re: [RFC 0/3] extend kexec_file_load system call
Russell King - ARM Linux <linux@...linux.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.
Powered by blists - more mailing lists