Re: [PATCH v8 01/27] Documentation/x86: Add CET description

2019-08-14 Thread Florian Weimer
* Yu-cheng Yu: > +ENDBR > +The compiler inserts an ENDBR at all valid branch targets. Any > +CALL/JMP to a target without an ENDBR triggers a control > +protection fault. Is this really correct? I think ENDBR is needed only for indirect branch targets where the jump/call does not ha

Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file

2019-06-10 Thread Florian Weimer
* 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 H

Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function

2019-06-10 Thread Florian Weimer
* Yu-cheng Yu: > On Fri, 2019-06-07 at 14:09 -0700, Dave Hansen wrote: >> On 6/7/19 1:06 PM, Yu-cheng Yu wrote: >> > > Huh, how does glibc know about all possible past and future legacy code >> > > in the application? >> > >> > When dlopen() gets a legacy binary and the policy allows that, it wil

Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function

2019-06-11 Thread Florian Weimer
* Dave Hansen: > My assumption has always been that these large, potentially sparse > hardware tables *must* be mmap()'d with MAP_NORESERVE specified. That > should keep them from being problematic with respect to overcommit. MAP_NORESERVE pages still count towards the commit limit. The flag on

Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file

2019-06-17 Thread Florian Weimer
* Dave Martin: > On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote: >> On Tue, 2019-06-11 at 12:41 +0100, Dave Martin wrote: >> > On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote: >> > > * Yu-cheng Yu: >> > > >> > >

Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file

2019-06-18 Thread Florian Weimer
* Peter Zijlstra: > I'm not sure I read Thomas' comment like that. In my reading keeping the > PT_NOTE fallback is exactly one of those 'fly workarounds'. By not > supporting PT_NOTE only the 'fine' people already shit^Hpping this out > of tree are affected, and we don't have to care about them at

Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file

2019-06-18 Thread Florian Weimer
* Yu-cheng Yu: > The kernel looks at only ld-linux. Other applications are loaded by > ld-linux. > So the issues are limited to three versions of ld-linux's. Can we somehow > update those?? I assumed that it would also parse the main executable and make adjustments based on that. ld.so can c

Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file

2019-06-18 Thread Florian Weimer
* 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

Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file

2019-06-18 Thread Florian Weimer
* 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 >> >

Re: [PATCH] binfmt_elf: Extract .note.gnu.property from an ELF file

2019-06-27 Thread Florian Weimer
* Andy Lutomirski: > Also, I don't think there's any actual requirement that the upstream > kernel recognize existing CET-enabled RHEL 8 binaries as being > CET-enabled. I tend to think that RHEL 8 jumped the gun here. The ABI was supposed to be finalized and everyone involved thought it had bee

Re: [PATCH v7 resend 00/20] ILP32 for ARM64

2017-04-11 Thread Florian Weimer
On 04/11/2017 08:36 PM, Yury Norov wrote: Also, the latest benchmarks I've seen were mostly for user space while I'm more concerned with the user-kernel interface (https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2). On the glibc testing side, have the regressions been identified/fixe

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

2017-11-06 Thread Florian Weimer
* Ram Pai: > Testing: > --- > This patch series has passed all the protection key > tests available in the selftest directory.The > tests are updated to work on both x86 and powerpc. > The selftests have passed on x86 and powerpc hardware. How do you deal with the key reuse problem? Is it th

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

2017-11-06 Thread Florian Weimer
* Ram Pai: > On Mon, Nov 06, 2017 at 10:28:41PM +0100, Florian Weimer wrote: >> * Ram Pai: >> >> > Testing: >> > --- >> > This patch series has passed all the protection key >> > tests available in the selftest directory.The >> >

Re: [RFC PATCH v4 6/9] x86/cet/ibt: Add arch_prctl functions for IBT

2018-10-04 Thread Florian Weimer
* Yu-cheng Yu: > On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote: >> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote: >> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect >> > Branch Tracking features. >> > >> > Introduce: >> > >> > arch_prctl(ARCH_CET_L

Re: [PATCH v5 07/27] mm/mmap: Create a guard area between VMAs

2018-10-12 Thread Florian Weimer
* Dave Hansen: > On 10/11/2018 08:15 AM, Yu-cheng Yu wrote: >> Create a guard area between VMAs to detect memory corruption. > > This is a pretty major change that has a bunch of end-user implications. > It's not dependent on any debugging options and can't be turned on/off > by individual apps,