From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752979AbcGVAKB (ORCPT ); Thu, 21 Jul 2016 20:10:01 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51584 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752098AbcGVAJ7 (ORCPT ); Thu, 21 Jul 2016 20:09:59 -0400 X-IBM-Helo: d24dlp01.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, Jeremy Kerr , Michael Ellerman Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Thu, 21 Jul 2016 21:09:48 -0300 User-Agent: KMail/4.14.3 (Linux/3.13.0-92-generic; KDE/4.14.13; x86_64; ; ) In-Reply-To: <1808359.GMbkTHC4O6@hactar> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <3489461.zQnV5C1bXR@wuerfel> <1808359.GMbkTHC4O6@hactar> 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: 16072200-0032-0000-0000-0000026A5AB7 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16072200-0033-0000-0000-00000EA8B0AE Message-Id: <4197460.etrDupniY8@hactar> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-21_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607220001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Freitag, 15 Juli 2016, 18:03:35 schrieb Thiago Jung Bauermann: > Am Freitag, 15 Juli 2016, 22:26:09 schrieb Arnd Bergmann: > > 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. :-/ So even if not ideal, the solution above is desirable for powerpc. We would like to preserve the ability of allowing userspace to pass parameters to the OS via the DTB, even if secure boot is enabled. I would like to turn the above into a proposal: Extend the syscall as shown in this RFC from Takahiro AKASHI, but instead of accepting a complete DTB from userspace, the syscall accepts a DTB containing only a /chosen node. If the DTB contains any other node, the syscall fails with EINVAL. If the DTB contains any subnode in /chosen, or if there's a compatible or device_type property in /chosen, the syscall fails with EINVAL as well. 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