From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C541C31E40 for ; Mon, 10 Jun 2019 16:57:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 574F520859 for ; Mon, 10 Jun 2019 16:57:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387538AbfFJQ5i (ORCPT ); Mon, 10 Jun 2019 12:57:38 -0400 Received: from foss.arm.com ([217.140.110.172]:46232 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727648AbfFJQ5i (ORCPT ); Mon, 10 Jun 2019 12:57:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 027D7337; Mon, 10 Jun 2019 09:57:37 -0700 (PDT) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6B75A3F246; Mon, 10 Jun 2019 09:57:33 -0700 (PDT) Date: Mon, 10 Jun 2019 17:57:31 +0100 From: Dave Martin To: Yu-cheng Yu Cc: x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue Subject: Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file Message-ID: <20190610165730.GM28398@e103592.cambridge.arm.com> References: <20190606200646.3951-1-yu-cheng.yu@intel.com> <20190606200646.3951-23-yu-cheng.yu@intel.com> <20190607180115.GJ28398@e103592.cambridge.arm.com> <94b9c55b3b874825fda485af40ab2a6bc3dad171.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94b9c55b3b874825fda485af40ab2a6bc3dad171.camel@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 10, 2019 at 09:29:04AM -0700, Yu-cheng Yu wrote: > On Fri, 2019-06-07 at 19:01 +0100, Dave Martin wrote: > > On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote: > > > An ELF file's .note.gnu.property indicates features the executable file > > > can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND > > > indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or > > > GNU_PROPERTY_X86_FEATURE_1_SHSTK. > > > > > > With this patch, if an arch needs to setup features from ELF properties, > > > it needs CONFIG_ARCH_USE_GNU_PROPERTY to be set, and a specific > > > arch_setup_property(). > > > > > > For example, for X86_64: > > > > > > int arch_setup_property(void *ehdr, void *phdr, struct file *f, bool inter) > > > { > > > int r; > > > uint32_t property; > > > > > > r = get_gnu_property(ehdr, phdr, f, GNU_PROPERTY_X86_FEATURE_1_AND, > > > &property); > > > ... > > > } > > > > Although this code works for the simple case, I have some concerns about > > some aspects of the implementation here. There appear to be some bounds > > checking / buffer overrun issues, and the code seems quite complex. > > > > Maybe this patch tries too hard to be compatible with toolchains that do > > silly things such as embedding huge notes in an executable, or mixing > > NT_GNU_PROPERTY_TYPE_0 in a single PT_NOTE with a load of junk not > > relevant to the loader. I wonder whether Linux can dictate what > > interpretation(s) of the ELF specs it is prepared to support, rather than > > trying to support absolutely anything. > > To me, looking at PT_GNU_PROPERTY and not trying to support anything is a > logical choice. And it breaks only a limited set of toolchains. > > I will simplify the parser and leave this patch as-is for anyone who wants to > back-port. Are there any objections or concerns? No objection from me ;) But I'm biased. Hopefully this change should allow substantial simplification. For one thing, PT_GNU_PROPERTY tells its file offset and size directly in its phdrs entry. That should save us a lot of effort on the kernel side. Cheers ---Dave From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Martin Subject: Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file Date: Mon, 10 Jun 2019 17:57:31 +0100 Message-ID: <20190610165730.GM28398@e103592.cambridge.arm.com> References: <20190606200646.3951-1-yu-cheng.yu@intel.com> <20190606200646.3951-23-yu-cheng.yu@intel.com> <20190607180115.GJ28398@e103592.cambridge.arm.com> <94b9c55b3b874825fda485af40ab2a6bc3dad171.camel@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <94b9c55b3b874825fda485af40ab2a6bc3dad171.camel@intel.com> Sender: linux-kernel-owner@vger.kernel.org To: Yu-cheng Yu Cc: x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit List-Id: linux-api@vger.kernel.org On Mon, Jun 10, 2019 at 09:29:04AM -0700, Yu-cheng Yu wrote: > On Fri, 2019-06-07 at 19:01 +0100, Dave Martin wrote: > > On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote: > > > An ELF file's .note.gnu.property indicates features the executable file > > > can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND > > > indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or > > > GNU_PROPERTY_X86_FEATURE_1_SHSTK. > > > > > > With this patch, if an arch needs to setup features from ELF properties, > > > it needs CONFIG_ARCH_USE_GNU_PROPERTY to be set, and a specific > > > arch_setup_property(). > > > > > > For example, for X86_64: > > > > > > int arch_setup_property(void *ehdr, void *phdr, struct file *f, bool inter) > > > { > > > int r; > > > uint32_t property; > > > > > > r = get_gnu_property(ehdr, phdr, f, GNU_PROPERTY_X86_FEATURE_1_AND, > > > &property); > > > ... > > > } > > > > Although this code works for the simple case, I have some concerns about > > some aspects of the implementation here. There appear to be some bounds > > checking / buffer overrun issues, and the code seems quite complex. > > > > Maybe this patch tries too hard to be compatible with toolchains that do > > silly things such as embedding huge notes in an executable, or mixing > > NT_GNU_PROPERTY_TYPE_0 in a single PT_NOTE with a load of junk not > > relevant to the loader. I wonder whether Linux can dictate what > > interpretation(s) of the ELF specs it is prepared to support, rather than > > trying to support absolutely anything. > > To me, looking at PT_GNU_PROPERTY and not trying to support anything is a > logical choice. And it breaks only a limited set of toolchains. > > I will simplify the parser and leave this patch as-is for anyone who wants to > back-port. Are there any objections or concerns? No objection from me ;) But I'm biased. Hopefully this change should allow substantial simplification. For one thing, PT_GNU_PROPERTY tells its file offset and size directly in its phdrs entry. That should save us a lot of effort on the kernel side. Cheers ---Dave