From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751610AbcGOU1j (ORCPT <rfc822;w@1wt.eu>);
	Fri, 15 Jul 2016 16:27:39 -0400
Received: from mout.kundenserver.de ([212.227.126.135]:60086 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751413AbcGOU1h (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 15 Jul 2016 16:27:37 -0400
From: Arnd Bergmann <arnd@arndb.de>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Vivek Goyal <vgoyal@redhat.com>, Mark Rutland <mark.rutland@arm.com>,
        Stewart Smith <stewart@linux.vnet.ibm.com>,
        Mimi Zohar <zohar@linux.vnet.ibm.com>, bhe@redhat.com,
        linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org,
        linux-kernel@vger.kernel.org,
        AKASHI Takahiro <takahiro.akashi@linaro.org>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
        Samuel Mendoza-Jonas <sam@mendozajonas.com>,
        Dave Young <dyoung@redhat.com>, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 0/3] extend kexec_file_load system call
Date: Fri, 15 Jul 2016 22:26:09 +0200
Message-ID: <3489461.zQnV5C1bXR@wuerfel>
User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; )
In-Reply-To: <20160715134209.GF1041@n2100.armlinux.org.uk>
References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <20160715132610.GD23514@redhat.com> <20160715134209.GF1041@n2100.armlinux.org.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:Mj4S97inxgVfTj0HD9wGoiDwnRv18b2d/dLjhBiZLGeIdVt6Vdg
 eb+G+nGe5+oKr/tKj9J2xfGyJcOYyQbOiJrQmbjrMCIsyjFCfQCFGtb1yPEhv67/an9HR/K
 ECERHXlUd7zEw0cqP/xdKzgDDPI7VpOgc3MKzOEBdGqJPilySSt5d4LsvrsaCPYgNlqYWVf
 l8jAuSY4AEtnV4D09dGAg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:O7TM8IdpuSE=:FP5kxTgrXmxWgnsrTdxOoY
 3I/MVrInmVbSRxw8vRytgiPSAyzdRXAkdyK5m7/wXifcqKOPuRm23lkVy10FOP+TNqPrTVaUv
 9QEFqz0yB1ukax2LVI98voeMwtuIDLc0M401ewhx80TfWX5GCVEjM0F2w3UCPfjTC+pau6OVF
 2r6xWwPrLoPjbELuSRcAhKdnT7ZT74EQ0HlsgbvIo79paFwDBT7vNqWzCkM1y2GBrkGbWr5oc
 o3vmKAzGSybCxtBIKZEcIQIdc1EVX3yfWZh2bSQiOnlOO+2IaCVQgG+tgmnvxT8nuzgld41Ya
 pmqe1LBhPYB8B+Pa57coQZxCqolVnYTHmmDFdODl2gfliEg6mF6ZIvRJtwVweYjuPYHvJC+yY
 9pSQbdXwQNLeyxbUFrEE2b8uK8HU/FFU2XQT785yZ9p0MLSa0KtWLdh7J5knwIgBxCn01e4eR
 ujjuWiW1Qx16P4gdQALPhpU5pxrp2YGf5TloV+7yV5v0OTID5sPFnkd/Bj32VhBLiohIrw6E0
 ZAKvUDKeTAH5rOlqp1l/I6PIxKZvnOC+x3bQ+prNgUCWK9/OCEOyEDIqUQ9c2e7spk3rZmhna
 IbxuCc/tYRMsa5UppvtgMdTi5p1/+3jc+KSyev/n9UhcG6mQfk7g6dWRufy7L213BueJqVkHm
 u/IKjl9ATNjlsOF98AKzwb99Wp2GGl+YUNPtR8fIcDWca9fe04cDQMuO7y6yVXMvuW6GZIq9k
 xj77UfnX5xPfPF5L
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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