From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file Date: Tue, 18 Jun 2019 18:25:51 +0200 Message-ID: <8736k67tdc.fsf@oldenburg2.str.redhat.com> References: <20190618091248.GB2790@e103592.cambridge.arm.com> <20190618124122.GH3419@hirez.programming.kicks-ass.net> <87ef3r9i2j.fsf@oldenburg2.str.redhat.com> <20190618125512.GJ3419@hirez.programming.kicks-ass.net> <20190618133223.GD2790@e103592.cambridge.arm.com> <87pnna7v1d.fsf@oldenburg2.str.redhat.com> <1ca57aaae8a2121731f2dcb1a137b92eed39a0d2.camel@intel.com> <87blyu7ubf.fsf@oldenburg2.str.redhat.com> <20190618162005.GF2790@e103592.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <20190618162005.GF2790@e103592.cambridge.arm.com> (Dave Martin's message of "Tue, 18 Jun 2019 17:20:07 +0100") Sender: linux-kernel-owner@vger.kernel.org To: Dave Martin Cc: Yu-cheng Yu , Peter Zijlstra , Thomas Gleixner , x86@kernel.org, "H. Peter Anvin" , 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 , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz List-Id: linux-api@vger.kernel.org * Dave Martin: > On Tue, Jun 18, 2019 at 09:00:35AM -0700, Yu-cheng Yu wrote: >> On Tue, 2019-06-18 at 18:05 +0200, Florian Weimer wrote: >> > * Yu-cheng Yu: >> > >> > > > I assumed that it would also parse the main executable and make >> > > > adjustments based on that. >> > > >> > > Yes, Linux also looks at the main executable's header, but not its >> > > NT_GNU_PROPERTY_TYPE_0 if there is a loader. >> > > >> > > > >> > > > ld.so can certainly provide whatever the kernel needs. We need to tweak >> > > > the existing loader anyway. >> > > > >> > > > No valid statically-linked binaries exist today, so this is not a >> > > > consideration at this point. >> > > >> > > So from kernel, we look at only PT_GNU_PROPERTY? >> > >> > If you don't parse notes/segments in the executable for CET, then yes. >> > We can put PT_GNU_PROPERTY into the loader. >> >> Thanks! > > Would this require the kernel and ld.so to be updated in a particular > order to avoid breakage? I don't know enough about RHEL to know how > controversial that might be. There is no official ld.so that will work with the current userspace interface (in this patch submission). Upstream glibc needs to be updated anyway, so yet another change isn't much of an issue. This is not a problem; we knew that something like this might happen. Sure, people need a new binutils with backports for PT_GNU_PROPERTY, but given that only very few people will build CET binaries with older binutils, I think that's not a real issue either. Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:57784 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729295AbfFRQ0Q (ORCPT ); Tue, 18 Jun 2019 12:26:16 -0400 From: Florian Weimer Subject: Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file References: <20190618091248.GB2790@e103592.cambridge.arm.com> <20190618124122.GH3419@hirez.programming.kicks-ass.net> <87ef3r9i2j.fsf@oldenburg2.str.redhat.com> <20190618125512.GJ3419@hirez.programming.kicks-ass.net> <20190618133223.GD2790@e103592.cambridge.arm.com> <87pnna7v1d.fsf@oldenburg2.str.redhat.com> <1ca57aaae8a2121731f2dcb1a137b92eed39a0d2.camel@intel.com> <87blyu7ubf.fsf@oldenburg2.str.redhat.com> <20190618162005.GF2790@e103592.cambridge.arm.com> Date: Tue, 18 Jun 2019 18:25:51 +0200 In-Reply-To: <20190618162005.GF2790@e103592.cambridge.arm.com> (Dave Martin's message of "Tue, 18 Jun 2019 17:20:07 +0100") Message-ID: <8736k67tdc.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-arch-owner@vger.kernel.org List-ID: To: Dave Martin Cc: Yu-cheng Yu , Peter Zijlstra , Thomas Gleixner , x86@kernel.org, "H. Peter Anvin" , 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 , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue Message-ID: <20190618162551.zdgFWBUll75qA75xEJWwc9gpt2ibdDexmxqTB38ueIo@z> * Dave Martin: > On Tue, Jun 18, 2019 at 09:00:35AM -0700, Yu-cheng Yu wrote: >> On Tue, 2019-06-18 at 18:05 +0200, Florian Weimer wrote: >> > * Yu-cheng Yu: >> > >> > > > I assumed that it would also parse the main executable and make >> > > > adjustments based on that. >> > > >> > > Yes, Linux also looks at the main executable's header, but not its >> > > NT_GNU_PROPERTY_TYPE_0 if there is a loader. >> > > >> > > > >> > > > ld.so can certainly provide whatever the kernel needs. We need to tweak >> > > > the existing loader anyway. >> > > > >> > > > No valid statically-linked binaries exist today, so this is not a >> > > > consideration at this point. >> > > >> > > So from kernel, we look at only PT_GNU_PROPERTY? >> > >> > If you don't parse notes/segments in the executable for CET, then yes. >> > We can put PT_GNU_PROPERTY into the loader. >> >> Thanks! > > Would this require the kernel and ld.so to be updated in a particular > order to avoid breakage? I don't know enough about RHEL to know how > controversial that might be. There is no official ld.so that will work with the current userspace interface (in this patch submission). Upstream glibc needs to be updated anyway, so yet another change isn't much of an issue. This is not a problem; we knew that something like this might happen. Sure, people need a new binutils with backports for PT_GNU_PROPERTY, but given that only very few people will build CET binaries with older binutils, I think that's not a real issue either. Thanks, Florian