[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3489461.zQnV5C1bXR@wuerfel>
Date: Fri, 15 Jul 2016 22:26:09 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Vivek Goyal <vgoyal@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Stewart Smith <stewart@...ux.vnet.ibm.com>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>, bhe@...hat.com,
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>,
Samuel Mendoza-Jonas <sam@...dozajonas.com>,
Dave Young <dyoung@...hat.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC 0/3] extend kexec_file_load system call
On Friday, July 15, 2016 2:42:10 PM CEST Russell King - ARM Linux wrote:
>
> On other architectures, DT can also contain open-firmware "functions"
> but I don't think there's much support in the kernel for that - maybe
> the PPC folk can reply on that point.
The open firmware runtime interface are shut down by the time we have
a flattened device tree, so those are not accessible any more. IIRC
SPARC leaves the open firmware interface live, but it doesn't use
fdt, so that's not relevant here.
However, the powerpc specific RTAS runtime services provide a similar
interface to the UEFI runtime support and allow to call into
binary code from the kernel, which gets mapped from a physical
address in the "linux,rtas-base" property in the rtas device node.
Modifying the /rtas node will definitely give you a backdoor into
priviledged code, but modifying only /chosen should not let you get
in through that specific method.
Arnd
Powered by blists - more mailing lists