From: Dave Martin <Dave.Martin@arm.com> To: Florian Weimer <fweimer@redhat.com> Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, 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 <arnd@arndb.de>, Andy Lutomirski <luto@amacapital.net>, Balbir Singh <bsingharora@gmail.com>, Borislav Petkov <bp@alien8.de>, Cyrill Gorcunov <gorcunov@gmail.com>, Dave Hansen <dave.hansen@linux.intel.com>, Eugene Syromiatnikov <esyr@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, Mike Kravetz <mike.kravetz@oracle.com>, Nadav Amit <nadav.amit@gmail.com>, Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>, Peter Zijlstra <peterz@infradead.org>, Randy Dunlap <rdunlap@infradead.org>, "Ravi V. Shankar" <ravi.v.shankar@intel.com>, Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com> Subject: Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file Date: Tue, 11 Jun 2019 12:41:09 +0100 [thread overview] Message-ID: <20190611114109.GN28398@e103592.cambridge.arm.com> (raw) In-Reply-To: <87lfy9cq04.fsf@oldenburg2.str.redhat.com> On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote: > * Yu-cheng Yu: > > > 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? > > Red Hat Enterprise Linux 8 does not use PT_GNU_PROPERTY and is probably > the largest collection of CET-enabled binaries that exists today. For clarity, RHEL is actively parsing these properties today? > My hope was that we would backport the upstream kernel patches for CET, > port the glibc dynamic loader to the new kernel interface, and be ready > to run with CET enabled in principle (except that porting userspace > libraries such as OpenSSL has not really started upstream, so many > processes where CET is particularly desirable will still run without > it). > > I'm not sure if it is a good idea to port the legacy support if it's not > part of the mainline kernel because it comes awfully close to creating > our own private ABI. I guess we can aim to factor things so that PT_NOTE scanning is available as a fallback on arches for which the absence of PT_GNU_PROPERTY is not authoritative. Can we argue that the lack of PT_GNU_PROPERTY is an ABI bug, fix it for new binaries and hence limit the efforts we go to to support theoretical binaries that lack the phdrs entry? If we can make practical simplifications to the parsing, such as limiting the maximum PT_NOTE size that we will search for the program properties to 1K (say), or requiring NT_NOTE_GNU_PROPERTY_TYPE_0 to sit by itself in a single PT_NOTE then that could help minimse the exec overheads and the number of places for bugs to hide in the kernel. What we can do here depends on what the tools currently do and what binaries are out there. Cheers ---Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Martin <Dave.Martin@arm.com> To: Florian Weimer <fweimer@redhat.com> Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, 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 <arnd@arndb.de>, Andy Lutomirski <luto@amacapital.net>, Balbir Singh <bsingharora@gmail.com>, Borislav Petkov <bp@alien8.de>, Cyrill Gorcunov <gorcunov@gmail.com>, Dave Hansen <dave.hansen@linux.intel.com>, Eugene Syromiatnikov <esyr@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, Mike Kravetz <mike.kravetz@oracle.com>, Nadav Amit <nadav.amit@gmail.com> Subject: Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file Date: Tue, 11 Jun 2019 12:41:09 +0100 [thread overview] Message-ID: <20190611114109.GN28398@e103592.cambridge.arm.com> (raw) In-Reply-To: <87lfy9cq04.fsf@oldenburg2.str.redhat.com> On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote: > * Yu-cheng Yu: > > > 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? > > Red Hat Enterprise Linux 8 does not use PT_GNU_PROPERTY and is probably > the largest collection of CET-enabled binaries that exists today. For clarity, RHEL is actively parsing these properties today? > My hope was that we would backport the upstream kernel patches for CET, > port the glibc dynamic loader to the new kernel interface, and be ready > to run with CET enabled in principle (except that porting userspace > libraries such as OpenSSL has not really started upstream, so many > processes where CET is particularly desirable will still run without > it). > > I'm not sure if it is a good idea to port the legacy support if it's not > part of the mainline kernel because it comes awfully close to creating > our own private ABI. I guess we can aim to factor things so that PT_NOTE scanning is available as a fallback on arches for which the absence of PT_GNU_PROPERTY is not authoritative. Can we argue that the lack of PT_GNU_PROPERTY is an ABI bug, fix it for new binaries and hence limit the efforts we go to to support theoretical binaries that lack the phdrs entry? If we can make practical simplifications to the parsing, such as limiting the maximum PT_NOTE size that we will search for the program properties to 1K (say), or requiring NT_NOTE_GNU_PROPERTY_TYPE_0 to sit by itself in a single PT_NOTE then that could help minimse the exec overheads and the number of places for bugs to hide in the kernel. What we can do here depends on what the tools currently do and what binaries are out there. Cheers ---Dave
next prev parent reply other threads:[~2019-06-11 11:41 UTC|newest] Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-06 20:06 [PATCH v7 00/27] Control-flow Enforcement: Shadow Stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 01/27] Documentation/x86: Add CET description Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 02/27] x86/cpufeatures: Add CET CPU feature flags for Control-flow Enforcement Technology (CET) Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 03/27] x86/fpu/xstate: Change names to separate XSAVES system and user states Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 04/27] x86/fpu/xstate: Introduce XSAVES system states Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 21:18 ` Dave Hansen 2019-06-06 21:18 ` Dave Hansen 2019-06-06 22:04 ` Andy Lutomirski 2019-06-06 22:04 ` Andy Lutomirski 2019-06-06 22:08 ` Dave Hansen 2019-06-06 22:08 ` Dave Hansen 2019-06-06 22:10 ` Yu-cheng Yu 2019-06-06 22:10 ` Yu-cheng Yu 2019-06-06 22:10 ` Yu-cheng Yu 2019-06-07 1:54 ` Andy Lutomirski 2019-06-07 1:54 ` Andy Lutomirski 2019-06-06 20:06 ` [PATCH v7 05/27] x86/fpu/xstate: Add XSAVES system states for shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:07 ` Peter Zijlstra 2019-06-07 7:07 ` Peter Zijlstra 2019-06-07 16:14 ` Yu-cheng Yu 2019-06-07 16:14 ` Yu-cheng Yu 2019-06-07 16:14 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 06/27] x86/cet: Add control protection exception handler Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 07/27] x86/cet/shstk: Add Kconfig option for user-mode shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 08/27] mm: Introduce VM_SHSTK for shadow stack memory Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 09/27] mm/mmap: Prevent Shadow Stack VMA merges Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 10/27] x86/mm: Change _PAGE_DIRTY to _PAGE_DIRTY_HW Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 11/27] x86/mm: Introduce _PAGE_DIRTY_SW Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 12/27] drm/i915/gvt: Update _PAGE_DIRTY to _PAGE_DIRTY_BITS Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 13/27] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 14/27] x86/mm: Shadow stack page fault error checking Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 15/27] mm: Handle shadow stack page fault Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:30 ` Peter Zijlstra 2019-06-07 7:30 ` Peter Zijlstra 2019-06-06 20:06 ` [PATCH v7 16/27] mm: Handle THP/HugeTLB " Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 17/27] mm: Update can_follow_write_pte/pmd for shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 18/27] mm: Introduce do_mmap_locked() Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:43 ` Peter Zijlstra 2019-06-07 7:43 ` Peter Zijlstra 2019-06-07 7:47 ` Peter Zijlstra 2019-06-07 7:47 ` Peter Zijlstra 2019-06-07 16:16 ` Yu-cheng Yu 2019-06-07 16:16 ` Yu-cheng Yu 2019-06-07 16:16 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 19/27] x86/cet/shstk: User-mode shadow stack support Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 20/27] x86/cet/shstk: Introduce WRUSS instruction Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 21/27] x86/cet/shstk: Handle signals for shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:58 ` Peter Zijlstra 2019-06-07 7:58 ` Peter Zijlstra 2019-06-07 16:17 ` Yu-cheng Yu 2019-06-07 16:17 ` Yu-cheng Yu 2019-06-07 16:17 ` Yu-cheng Yu 2019-06-07 18:01 ` Dave Martin 2019-06-07 18:01 ` Dave Martin 2019-06-10 16:29 ` Yu-cheng Yu 2019-06-10 16:29 ` Yu-cheng Yu 2019-06-10 16:29 ` Yu-cheng Yu 2019-06-10 16:57 ` Dave Martin 2019-06-10 16:57 ` Dave Martin 2019-06-10 17:24 ` Florian Weimer 2019-06-10 17:24 ` Florian Weimer 2019-06-10 17:24 ` Florian Weimer 2019-06-11 11:41 ` Dave Martin [this message] 2019-06-11 11:41 ` Dave Martin 2019-06-11 19:31 ` Yu-cheng Yu 2019-06-11 19:31 ` Yu-cheng Yu 2019-06-11 19:31 ` Yu-cheng Yu 2019-06-12 9:32 ` Dave Martin 2019-06-12 9:32 ` Dave Martin 2019-06-12 19:04 ` Yu-cheng Yu 2019-06-12 19:04 ` Yu-cheng Yu 2019-06-12 19:04 ` Yu-cheng Yu 2019-06-13 13:26 ` Dave Martin 2019-06-13 13:26 ` Dave Martin 2019-06-17 11:08 ` Florian Weimer 2019-06-17 11:08 ` Florian Weimer 2019-06-17 11:08 ` Florian Weimer 2019-06-17 12:20 ` Thomas Gleixner 2019-06-17 12:20 ` Thomas Gleixner 2019-06-17 12:20 ` Thomas Gleixner 2019-06-18 9:12 ` Dave Martin 2019-06-18 9:12 ` Dave Martin 2019-06-18 12:41 ` Peter Zijlstra 2019-06-18 12:41 ` Peter Zijlstra 2019-06-18 12:47 ` Florian Weimer 2019-06-18 12:47 ` Florian Weimer 2019-06-18 12:47 ` Florian Weimer 2019-06-18 12:55 ` Peter Zijlstra 2019-06-18 12:55 ` Peter Zijlstra 2019-06-18 13:32 ` Dave Martin 2019-06-18 13:32 ` Dave Martin 2019-06-18 13:32 ` Dave Martin 2019-06-18 13:32 ` Dave Martin 2019-06-18 14:58 ` Yu-cheng Yu 2019-06-18 14:58 ` Yu-cheng Yu 2019-06-18 14:58 ` Yu-cheng Yu 2019-06-18 15:49 ` Florian Weimer 2019-06-18 15:49 ` Florian Weimer 2019-06-18 15:49 ` Florian Weimer 2019-06-18 15:53 ` Yu-cheng Yu 2019-06-18 15:53 ` Yu-cheng Yu 2019-06-18 15:53 ` Yu-cheng Yu 2019-06-18 16:05 ` Florian Weimer 2019-06-18 16:05 ` Florian Weimer 2019-06-18 16:05 ` Florian Weimer 2019-06-18 16:00 ` Yu-cheng Yu 2019-06-18 16:00 ` Yu-cheng Yu 2019-06-18 16:00 ` Yu-cheng Yu 2019-06-18 16:20 ` Dave Martin 2019-06-18 16:20 ` Dave Martin 2019-06-18 16:25 ` Florian Weimer 2019-06-18 16:25 ` Florian Weimer 2019-06-18 16:25 ` Florian Weimer 2019-06-18 16:50 ` Dave Martin 2019-06-18 16:50 ` Dave Martin 2019-06-06 20:06 ` [PATCH v7 23/27] x86/cet/shstk: ELF header parsing of Shadow Stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-07 7:54 ` Peter Zijlstra 2019-06-07 7:54 ` Peter Zijlstra 2019-06-06 20:06 ` [PATCH v7 24/27] x86/cet/shstk: Handle thread shadow stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 25/27] mm/mmap: Add Shadow stack pages to memory accounting Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-11 17:55 ` Dave Hansen 2019-06-11 17:55 ` Dave Hansen 2019-06-11 19:22 ` Yu-cheng Yu 2019-06-11 19:22 ` Yu-cheng Yu 2019-06-11 19:22 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 26/27] x86/cet/shstk: Add arch_prctl functions for Shadow Stack Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-06-06 20:06 ` [PATCH v7 27/27] x86/cet/shstk: Add Shadow Stack instructions to opcode map Yu-cheng Yu 2019-06-06 20:06 ` Yu-cheng Yu 2019-11-01 14:03 ` Adrian Hunter 2019-11-01 14:03 ` Adrian Hunter 2019-11-01 14:17 ` Yu-cheng Yu 2019-11-01 14:17 ` Yu-cheng Yu 2019-11-01 14:17 ` Yu-cheng Yu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190611114109.GN28398@e103592.cambridge.arm.com \ --to=dave.martin@arm.com \ --cc=arnd@arndb.de \ --cc=bp@alien8.de \ --cc=bsingharora@gmail.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@linux.intel.com \ --cc=esyr@redhat.com \ --cc=fweimer@redhat.com \ --cc=gorcunov@gmail.com \ --cc=hjl.tools@gmail.com \ --cc=hpa@zytor.com \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=luto@amacapital.net \ --cc=mike.kravetz@oracle.com \ --cc=mingo@redhat.com \ --cc=nadav.amit@gmail.com \ --cc=oleg@redhat.com \ --cc=pavel@ucw.cz \ --cc=peterz@infradead.org \ --cc=ravi.v.shankar@intel.com \ --cc=rdunlap@infradead.org \ --cc=tglx@linutronix.de \ --cc=vedvyas.shanbhogue@intel.com \ --cc=x86@kernel.org \ --cc=yu-cheng.yu@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.