From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751576AbcGOVDs (ORCPT ); Fri, 15 Jul 2016 17:03:48 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57690 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751276AbcGOVDp (ORCPT ); Fri, 15 Jul 2016 17:03:45 -0400 X-IBM-Helo: d24dlp02.br.ibm.com X-IBM-MailFrom: bauerman@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org From: Thiago Jung Bauermann To: Arnd Bergmann Cc: Russell King - ARM Linux , Vivek Goyal , Mark Rutland , Stewart Smith , Mimi Zohar , bhe@redhat.com, linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro , "Eric W. Biederman" , Samuel Mendoza-Jonas , Dave Young , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Fri, 15 Jul 2016 18:03:35 -0300 User-Agent: KMail/4.14.3 (Linux/3.13.0-91-generic; KDE/4.14.13; x86_64; ; ) In-Reply-To: <3489461.zQnV5C1bXR@wuerfel> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <20160715134209.GF1041@n2100.armlinux.org.uk> <3489461.zQnV5C1bXR@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16071521-0028-0000-0000-000001259A2A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16071521-0029-0000-0000-000013D13D07 Message-Id: <1808359.GMbkTHC4O6@hactar> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-15_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607150221 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Freitag, 15 Juli 2016, 22:26:09 schrieb Arnd Bergmann: > 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. Except that arch/powerpc/kernel/rtas.c looks for any node in the tree called "rtas", so it will try to use /chosen/rtas, or /chosen/foo/rtas. We can forbid subnodes in /chosen in the dtb passed to kexec_file_load, though that means userspace can't use the simple-framebuffer binding via this mechanism. We also have to blacklist the device_type and compatible properties in /chosen to avoid the problem Mark mentioned. Still doable, but not ideal. :-/ -- []'s Thiago Jung Bauermann IBM Linux Technology Center