From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753304AbcGVAx6 (ORCPT ); Thu, 21 Jul 2016 20:53:58 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:38968 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751951AbcGVAxz (ORCPT ); Thu, 21 Jul 2016 20:53:55 -0400 X-IBM-Helo: d23dlp02.au.ibm.com X-IBM-MailFrom: jeremy.kerr@au1.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Subject: Re: [RFC 0/3] extend kexec_file_load system call To: Thiago Jung Bauermann , Arnd Bergmann References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <3489461.zQnV5C1bXR@wuerfel> <1808359.GMbkTHC4O6@hactar> <4197460.etrDupniY8@hactar> 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 From: Jeremy Kerr Date: Fri, 22 Jul 2016 08:53:41 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4197460.etrDupniY8@hactar> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16072200-0012-0000-0000-000001AE1B40 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16072200-0013-0000-0000-0000059F5BF9 Message-Id: <7619c6f9-689e-f062-08d4-0d11a2df66ad@au.ibm.com> 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=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607220011 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thiago, > 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. This works for me. We could even have it as just a DTB fragment that is merged *at* the /chosen/ node of the kernel-device tree - so would not contain a /chosen node itself, and it would be impossible to provide nodes outside of /chosen. Either is fine. Thanks! Jeremy