ppc64 sbrk returns executable heap in 32-bit emulation mode

We noticed that on ppc64, the sbrk system call in the 32-bit subsystem returns executable memory. I assume it is related to this, in arch/powerpc/include/asm/page.h: /* * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI, * and needs to be executable. This means the whole heap ends

Re: ppc64 sbrk returns executable heap in 32-bit emulation mode

On 05/16/2016 11:09 AM, Andreas Schwab wrote: Florian Weimer <fwei...@redhat.com> writes: But my test says that at least part of .bss in the main executable is *not* executable. Build with -mbss-plt -Wl,--bss-plt. This gives me: FAIL exec .bss data (unexpected result) FAI

Re: ppc64 sbrk returns executable heap in 32-bit emulation mode

On 05/16/2016 10:49 AM, Andreas Schwab wrote: (If I'm wrong about heap+stack needing the same protection then I can't think of any reason to require an executable heap.) The heap and the BSS initially share the same page. But my test says that at least part of .bss in the main executable

Re: ppc64 sbrk returns executable heap in 32-bit emulation mode

On 05/16/2016 08:24 AM, Alan Modra wrote: On Thu, May 12, 2016 at 03:41:09PM +0200, Florian Weimer wrote: We noticed that on ppc64, the sbrk system call in the 32-bit subsystem returns executable memory. I assume it is related to this, in arch/powerpc/include/asm/page.h: /* * Unfortunately

Re: [PATCH v5] powerpc: Do not make the entire heap executable

* Jason Gunthorpe: > Eg that 32 bit powerpc currently unconditionally injects writable, > executable pages into a user space process. > > This critically undermines all the W^X security work that has been > done in the tool chain and user space by the PPC community. Exactly, this is how we found

Re: [PATCH 3/4] powerpc/powernv: Enable TM without suspend if possible

On 10/12/2017 12:17 PM, Michael Ellerman wrote: + pr_info("Enabling TM (Transactional Memory) with Suspend Disabled\n"); + cur_cpu_spec->cpu_features |= CPU_FTR_TM; + cur_cpu_spec->cpu_user_features2 |= PPC_FEATURE2_HTM_NO_SUSPEND; + tm_suspend_disabled = true; This

Re: [PATCH 3/4] powerpc/powernv: Enable TM without suspend if possible

On 10/19/2017 02:04 PM, Tulio Magno Quites Machado Filho wrote: Florian Weimer <fwei...@redhat.com> writes: On 10/12/2017 12:17 PM, Michael Ellerman wrote: + pr_info("Enabling TM (Transactional Memory) with Suspend Disabled\n"); + cur_cpu_spec->cpu_fea

POWER: Unexpected fault when writing to brk-allocated memory

We are seeing an issue on ppc64le and ppc64 (and perhaps on some arm variant, but I have not seen it on our own builders) where running localedef as part of the glibc build crashes with a segmentation fault. Kernel version is 4.13.9 (Fedora 26 variant). I have only seen this with an explicit

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/05/2017 01:18 PM, Nicholas Piggin wrote: Something like the following patch may help if you could test. The patch appears to fix it: # /lib64/ld64.so.1 ./a.out initial brk value: 0x7fffe459 probing at 0x8001fffc I used the follow simplified reproducer: #include #include

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/05/2017 01:18 PM, Nicholas Piggin wrote: There was a recent change to move to 128TB address space by default, and option for 512TB addresses if explicitly requested. Do you have a commit hash for the introduction of 128TB by default? Thanks. Your brk request asked for > 128TB which

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 07:47 AM, Nicholas Piggin wrote: "You get < 128TB unless explicitly requested." Simple, reasonable, obvious rule. Avoids breaking apps that store some bits in the top of pointers (provided that memory allocator userspace libraries also do the right thing). So brk would simplify

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 07:18 AM, Aneesh Kumar K.V wrote: We should not return that address, unless we requested with a hint value of > 128TB. IIRC we discussed this early during the mmap interface change and said, we will return an address > 128T only if the hint address is above 128TB (not hint addr +

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 09:30 AM, Aneesh Kumar K.V wrote: On 11/06/2017 01:55 PM, Nicholas Piggin wrote: On Mon, 6 Nov 2017 09:11:37 +0100 Florian Weimer <fwei...@redhat.com> wrote: On 11/06/2017 07:47 AM, Nicholas Piggin wrote: "You get < 128TB unless explicitly requested."

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

* 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

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

* 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: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 06:07 AM, Nicholas Piggin wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk() is a good example that steadily keeps incrementing address, so depending on malloc usage and address space

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk() is a good example that steadily keeps incrementing address, so depending on malloc usage and address space

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/08/2017 07:08 AM, Michael Ellerman wrote: "Kirill A. Shutemov" <kir...@shutemov.name> writes: On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote

Re: [PATCH 0/5] VA allocator fixes

On 11/06/2017 11:03 AM, Nicholas Piggin wrote: Florian found a nasty corner case with the VA allocation logic for crossing from 128TB to 512TB limit on hash, and made a really superb report of the problem -- traces, reproducer recipes, analysis, etc. which already mostly solved it. The first

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On 05/03/2018 01:38 AM, Ram Pai wrote: This is a new requirement that I was not aware off. Its not documented anywhere AFAICT. Correct. All inheritance behavior was deliberately left unspecified. I'm surprised about the reluctance to fix the x86 behavior. Are there any applications at all

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On 05/09/2018 04:41 PM, Andy Lutomirski wrote: Hmm. I can get on board with the idea that fork() / clone() / pthread_create() are all just special cases of the idea that the thread that*calls* them should have the right pkey values, and the latter is already busted given our inability to

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On 05/14/2018 05:32 PM, Andy Lutomirski wrote: On May 14, 2018, at 5:01 AM, Florian Weimer <fwei...@redhat.com> wrote: One thing we could do, though: the current initual state on process creation is all access blocked on all keys. We could change it so that half the keys are fully b

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On 05/08/2018 04:49 AM, Andy Lutomirski wrote: On Mon, May 7, 2018 at 2:48 AM Florian Weimer <fwei...@redhat.com> wrote: On 05/03/2018 06:05 AM, Andy Lutomirski wrote: On Wed, May 2, 2018 at 7:11 PM Ram Pai <linux...@us.ibm.com> wrote: On Wed, May 02, 2018 at 09:23:49PM

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On 05/16/2018 10:35 PM, Ram Pai wrote: So let me see if I understand the overall idea. Application can allocate new keys through a new syscall sys_pkey_alloc_1(flags, init_val, sig_init_val) 'sig_init_val' is the permission-state of the key in signal context. I would keep the existing system

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On 05/16/2018 11:07 PM, Ram Pai wrote: what would change the key-permission-values enforced in signal-handler context? Or can it never be changed, ones set through sys_pkey_alloc()? The access rights can only be set by pkey_alloc and are unchanged after that (so we do not have to discuss

Re: pkeys on POWER: Access rights not reset on execve

On 05/19/2018 03:50 AM, Andy Lutomirski wrote: Now another thread calls pkey_alloc(), so UAMR is asynchronously changed, and the thread will write zero to the relevant AMR bits. If I understand correctly, this means that the decision to mask off unallocated keys via UAMR effectively forces the

Re: pkeys on POWER: Access rights not reset on execve

On 05/19/2018 03:19 AM, Ram Pai wrote: New AMR value (PID 112291, before execl): 0x0c00 AMR (PID 112291): 0x0c00 The issue is here. The second line is after the execl (printed from the start of main), and the AMR value is not reset to zero. Allocated key (PID

Re: pkeys on POWER: Access rights not reset on execve

On 05/19/2018 03:19 AM, Ram Pai wrote: The issue you may be talking about here is that -- "when you set the AMR register to 0x, it just sets it to 0x0c00." To me it looks like, exec/fork are not related to the issue. Or are they also somehow connected to the issue?

Re: pkeys on POWER: Default AMR, UAMOR values

On 05/19/2018 02:52 AM, Ram Pai wrote: The POWER semantics make it very hard for a multithreaded program to meaningfully use protection keys to prevent accidental access to important memory. And you can change access rights for unallocated keys (unallocated at thread start time, allocated

Re: pkeys on POWER: Access rights not reset on execve

On 05/20/2018 09:11 PM, Ram Pai wrote: Florian, Does the following patch fix the problem for you? Just like x86 I am enabling all keys in the UAMOR register during initialization itself. Hence any key created by any thread at any time, will get activated on all

pkeys on POWER: Default AMR, UAMOR values

I'm working on adding POWER pkeys support to glibc. The coding work is done, but I'm faced with some test suite failures. Unlike the default x86 configuration, on POWER, existing threads have full access to newly allocated keys. Or, more precisely, in this scenario: * Thread A launches

pkeys on POWER: Access rights not reset on execve

This test program: #include #include #include #include #include #include /* Return the value of the AMR register. */ static inline unsigned long int pkey_read (void) { unsigned long int result; __asm__ volatile ("mfspr %0, 13" : "=r" (result)); return result; } /* Overwrite the

Re: pkeys on POWER: Default AMR, UAMOR values

On 05/18/2018 07:44 PM, Ram Pai wrote: Florian, is the behavior on x86 any different? A key allocated in the context off one thread is not meaningful in the context of any other thread. Since thread B was created prior to the creation of the key, and the key was created in the context of thread

Re: pkeys on POWER: Default AMR, UAMOR values

On 05/18/2018 09:39 PM, Andy Lutomirski wrote: The difference is that x86 starts out with deny-all instead of allow-all. The POWER semantics make it very hard for a multithreaded program to meaningfully use protection keys to prevent accidental access to important memory. And you can change

Re: [PATCH 5/5] powerpc/pkeys: make protection key 0 less special

On 06/05/2018 04:09 AM, Ram Pai wrote: diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h index 0409c80..d349e22 100644 --- a/arch/powerpc/include/asm/pkeys.h +++ b/arch/powerpc/include/asm/pkeys.h @@ -13,7 +13,10 @@ DECLARE_STATIC_KEY_TRUE(pkey_disabled);

Re: pkeys on POWER: Access rights not reset on execve

On 06/11/2018 10:08 PM, Ram Pai wrote: Ok. try this patch. This patch is on top of the 5 patches that I had sent last week i.e "[PATCH 0/5] powerpc/pkeys: fixes to pkeys" The following is a draft patch though to check if it meets your expectations. commit

Re: pkeys on POWER: Access rights not reset on execve

On 06/08/2018 03:49 PM, Michal Suchánek wrote: On Fri, 8 Jun 2018 14:57:06 +0200 Florian Weimer wrote: On 06/08/2018 02:54 PM, Michal Suchánek wrote: On Fri, 8 Jun 2018 12:44:53 +0200 Florian Weimer wrote: On 06/08/2018 12:15 PM, Michal Suchánek wrote: On Fri, 8 Jun 2018 07:53:51

Re: pkeys on POWER: Access rights not reset on execve

On 06/08/2018 02:54 PM, Michal Suchánek wrote: On Fri, 8 Jun 2018 12:44:53 +0200 Florian Weimer wrote: On 06/08/2018 12:15 PM, Michal Suchánek wrote: On Fri, 8 Jun 2018 07:53:51 +0200 Florian Weimer wrote: On 06/08/2018 04:34 AM, Ram Pai wrote: So the remaining question at this point

Re: pkeys on POWER: Access rights not reset on execve

On 06/08/2018 04:34 AM, Ram Pai wrote: So the remaining question at this point is whether the Intel behavior (default-deny instead of default-allow) is preferable. Florian, remind me what behavior needs to fixed? See the other thread. The Intel register equivalent to the AMR by default

Re: pkeys on POWER: Access rights not reset on execve

On 06/08/2018 12:15 PM, Michal Suchánek wrote: On Fri, 8 Jun 2018 07:53:51 +0200 Florian Weimer wrote: On 06/08/2018 04:34 AM, Ram Pai wrote: So the remaining question at this point is whether the Intel behavior (default-deny instead of default-allow) is preferable. Florian, remind me

Re: [PATCH v2 0/6] powerpc/pkeys: fixes to pkeys

The latter required some test fixes, but now passes as well. As far as I can tell, everything looks good now. Tested-By: Florian Weimer Thanks, Florian

Re: [PATCH v13 00/24] selftests, powerpc, x86 : Memory Protection Keys

On 06/14/2018 02:44 AM, Ram Pai wrote: Test Verified for correctness on powerpc. Need help verifying on x86. Compiles on x86. It breaks make in tools/testing/selftests/x86: make: *** No rule to make target `protection_keys.c', needed by

Re: pkeys on POWER: Access rights not reset on execve

On 06/11/2018 07:23 PM, Ram Pai wrote: On Fri, Jun 08, 2018 at 07:53:51AM +0200, Florian Weimer wrote: On 06/08/2018 04:34 AM, Ram Pai wrote: So the remaining question at this point is whether the Intel behavior (default-deny instead of default-allow) is preferable. Florian, remind me what

Re: pkeys on POWER: Access rights not reset on execve

On 06/03/2018 10:18 PM, Ram Pai wrote: On Mon, May 21, 2018 at 01:29:11PM +0200, Florian Weimer wrote: On 05/20/2018 09:11 PM, Ram Pai wrote: Florian, Does the following patch fix the problem for you? Just like x86 I am enabling all keys in the UAMOR register during

Re: pkeys on POWER: Access rights not reset on execve

On 06/04/2018 09:02 PM, Ram Pai wrote: On Mon, Jun 04, 2018 at 07:57:46PM +0200, Florian Weimer wrote: On 06/04/2018 04:01 PM, Ram Pai wrote: On Mon, Jun 04, 2018 at 12:12:07PM +0200, Florian Weimer wrote: On 06/03/2018 10:18 PM, Ram Pai wrote: On Mon, May 21, 2018 at 01:29:11PM +0200

Re: pkeys on POWER: Access rights not reset on execve

On 06/04/2018 04:01 PM, Ram Pai wrote: On Mon, Jun 04, 2018 at 12:12:07PM +0200, Florian Weimer wrote: On 06/03/2018 10:18 PM, Ram Pai wrote: On Mon, May 21, 2018 at 01:29:11PM +0200, Florian Weimer wrote: On 05/20/2018 09:11 PM, Ram Pai wrote: Florian, Does the following patch fix

Re: [PATCH v2 6/6] powerpc/pkeys: Deny read/write/execute by default

On 06/19/2018 02:39 PM, Michael Ellerman wrote: Ram Pai writes: Deny all permissions on all keys, with some exceptions. pkey-0 must allow all permissions, or else everything comes to a screaching halt. Execute-only key must allow execute permission. Another ABI change. Are we calling this

Kernel 4.15 lost set_robust_list support on POWER 9

I get this: 7041 set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not implemented) The system call works on 4.14. Looks like the probing for futex_cmpxchg_enabled goes wrong. Sorry, I have no idea where to start digging. I don't see anything obvious in dmesg. I'm trying to

Re: Kernel 4.15 lost set_robust_list support on POWER 9

On 02/05/2018 01:48 PM, Florian Weimer wrote: I get this: 7041  set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not implemented) The system call works on 4.14.  Looks like the probing for futex_cmpxchg_enabled goes wrong. Sorry, I have no idea where to start digging.  I don't

Re: [PATCH v2 0/6] powerpc/pkeys: fixes to pkeys

. Tested-By: Florian Weimer Thanks. I'll add that to each patch I guess, if you're happy with that? Sure, but I only tested the whole series as a whole. Thanks, Florian

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/14/2018 09:00 AM, Florian Weimer wrote: On 03/09/2018 09:00 PM, Ram Pai wrote: On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:00 PM, Ram Pai wrote: On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior. mprotect without a key does not necessarily use key 0, e.g. if protection keys are used to emulate page

Re: [PATCH] seccomp: Add pkru into seccomp_data

* Michael Sammler: > Add the current value of the PKRU register to data available for > seccomp-bpf programs to work on. This allows filters based on the > currently enabled protection keys. > diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h > index 9efc0e73..e8b9ecfc

Re: PIE binaries are no longer mapped below 4 GiB on ppc64le

* Michal Suchánek: > On Wed, 31 Oct 2018 18:20:56 +0100 > Florian Weimer wrote: > >> We tried to use Go to build PIE binaries, and while the Go toolchain >> is definitely not ready (it produces text relocations and problematic >> relocations in general), it exposed

PIE binaries are no longer mapped below 4 GiB on ppc64le

We tried to use Go to build PIE binaries, and while the Go toolchain is definitely not ready (it produces text relocations and problematic relocations in general), it exposed what could be an accidental userspace ABI change. With our 4.10-derived kernel, PIE binaries are mapped below 4 GiB, so

Re: PIE binaries are no longer mapped below 4 GiB on ppc64le

* Tulio Magno Quites Machado Filho: > Florian Weimer writes: > >> * Michal Suchánek: >> >>> On Wed, 31 Oct 2018 18:20:56 +0100 >>> Florian Weimer wrote: >>> >>>> And it needs to be built with: >>>> >>>> go build

Re: PIE binaries are no longer mapped below 4 GiB on ppc64le

* Michael Ellerman: > Hi Florian, > > Florian Weimer writes: >> We tried to use Go to build PIE binaries, and while the Go toolchain is >> definitely not ready (it produces text relocations and problematic >> relocations in general), it exposed what could be an acciden

Re: [PATCH] seccomp: Add pkru into seccomp_data

* Michael Sammler: > Thank you for the pointer about the POWER implementation. I am not > familiar with POWER in general and its protection key feature at > all. Would the AMR register be the correct register to expose here? Yes, according to my notes, the register is called AMR (special purpose

Re: [RFC PATCH v2 00/14] New TM Model

* Breno Leitao: > This patchset for the hardware transactional memory (TM) subsystem > aims to avoid spending a lot of time on TM suspended mode in kernel > space. It basically changes where the reclaim/recheckpoint will be > executed. I assumed that we want to abort on every system call these

Re: pkeys: Reserve PKEY_DISABLE_READ

* Ram Pai: > Florian, > > I can. But I am struggling to understand the requirement. Why is > this needed? Are we proposing a enhancement to the sys_pkey_alloc(), > to be able to allocate keys that are initialied to disable-read > only? Yes, I think that would be a

Re: pkeys: Reserve PKEY_DISABLE_READ

* Ram Pai: > On Thu, Nov 08, 2018 at 09:23:35PM +0100, Florian Weimer wrote: >> * Ram Pai: >> >> > Florian, >> > >> >I can. But I am struggling to understand the requirement. Why is >> >this needed? Are we proposing a enhancement to t

Re: pkeys: Reserve PKEY_DISABLE_READ

* Ram Pai: > On Thu, Nov 08, 2018 at 01:05:09PM +0100, Florian Weimer wrote: >> Would it be possible to reserve a bit for PKEY_DISABLE_READ? >> >> I think the POWER implementation can disable read access at the hardware >> level, but not write access, a

Re: [PATCH] powerpc/pkeys: copy pkey-tracking-information at fork()

* Ram Pai: > +void arch_dup_pkeys(struct mm_struct *oldmm, struct mm_struct *mm) > +{ > + /* Duplicate the oldmm pkey state in mm: */ > + mm_pkey_allocation_map(mm) = mm_pkey_allocation_map(oldmm); > + mm->context.execute_only_pkey = oldmm->context.execute_only_pkey; > +} Looks

Re: pkeys: Reserve PKEY_DISABLE_READ

* Ram Pai: > Ok. here is a patch, compiled but not tested. See if this meets the > specifications. > > --- > > commit 3dc06e73f3795921265d5d1d935e428deab01616 > Author: Ram Pai > Date: Tue Dec 4 00:04:11 2018 -0500

Re: pkeys: Reserve PKEY_DISABLE_READ

* Ram Pai: > So the problem is as follows: > > Currently the kernel supports 'disable-write' and 'disable-access'. > > On x86, cpu supports 'disable-write' and 'disable-access'. This > matches with what the kernel supports. All good. > > However on power, cpu supports 'disable-read' too. Since

Re: pkeys: Reserve PKEY_DISABLE_READ

* Dave Hansen: > On 11/27/18 3:57 AM, Florian Weimer wrote: >> I would have expected something that translates PKEY_DISABLE_WRITE | >> PKEY_DISABLE_READ into PKEY_DISABLE_ACCESS, and also accepts >> PKEY_DISABLE_ACCESS | PKEY_DISABLE_READ, for consistency with POWER. >

Re: pkeys: Reserve PKEY_DISABLE_READ

* Ram Pai: > diff --git a/arch/x86/include/uapi/asm/mman.h > b/arch/x86/include/uapi/asm/mman.h > index d4a8d04..e9b121b 100644 > --- a/arch/x86/include/uapi/asm/mman.h > +++ b/arch/x86/include/uapi/asm/mman.h > @@ -24,6 +24,11 @@ > ((key) & 0x2 ? VM_PKEY_BIT1 : 0) | \ >

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

* hpa: > PowerPC doesn't need it at all. Because the definition would be the same as struct termios? I think we should still define struct termios2 using the struct termios definition, and also define TCGETS2 and TCSETS2. This way, applications can use the struct termios2 type without

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

* Adhemerval Zanella: > This allows us to adjust the baud rates to non-standard values using termios > interfaces without to resorting to add new headers and use a different API > (ioctl). How much symbol versioning will be required for this change? > As Peter Anvin has indicated, he create a

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

* Adhemerval Zanella: > On 11/04/2019 08:07, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> This allows us to adjust the baud rates to non-standard values using termios >>> interfaces without to resorting to add new headers and use a different API &g

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

* Florian Weimer: > My gut feeling is that it's safer to add new interfaces, based on the > actual kernel/userspace interface, rather than trying to fix up existing > interfaces with symbol versioning. The main reason is that code > involving serial interfaces is difficult

Re: [PATCH] [RFC] Remove bdflush syscall stub

* Cyril Hrubis: > Hi! >> > I've tested the patch on i386. Before the patch calling bdflush() with >> > attempt to tune a variable returned 0 and after the patch the syscall >> > fails with EINVAL. >> >> Should be ENOSYS, doesn't it? > > My bad, the LTP syscall wrapper handles ENOSYS and produces

Re: [PATCH 1/2] open: add close_range()

* Christian Brauner: >> Solaris has an fdwalk function: >> >> >> >> So a different way to implement this would expose a nextfd system call > > Meh. If nextfd() then I would like it to be able to: > - get the nextfd(fd) >= fd

Re: [PATCH 1/2] open: add close_range()

* Christian Brauner: > +/** > + * __close_range() - Close all file descriptors in a given range. > + * > + * @fd: starting file descriptor to close > + * @max_fd: last file descriptor to close > + * > + * This closes a range of file descriptors. All file descriptors > + * from @fd up to and

[PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

. The expectation is that the kernel will eventually use the generic UAPI definition for struct termios2. 2019-04-09 Florian Weimer [BZ #10339] Linux: Define struct termios2 in under _GNU_SOURCE. * sysdeps/unix/sysv/linux/Makefile [$(subdir) == termios] (tests): Add tst

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

* hpa: > Anything blocking the POC code I provided? I don't recall that, sorry. Would you please provide a reference? Thanks, Florian

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

* hpa: > Using symbol versioning doesn't really help much since the real > problem is that struct termios can be passed around in userspace, and > the interfaces between user space libraries don't have any > versioning. However, my POC code deals with that too by only seeing > BOTHER when

Re: [PATCH v18 11/13] open: introduce openat2(2) syscall

* Aleksa Sarai: > diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h > index 1d338357df8a..58c3a0e543c6 100644 > --- a/include/uapi/linux/fcntl.h > +++ b/include/uapi/linux/fcntl.h > @@ -93,5 +93,40 @@ > > #define AT_RECURSIVE 0x8000 /* Apply to the entire subtree */

Re: powerpc Linux scv support and scv system call ABI proposal

* Segher Boessenkool: > On Wed, Jan 29, 2020 at 05:19:19PM +0100, Florian Weimer wrote: >> * Segher Boessenkool: >> >> But GCC doesn't expose them as integers to C code, so you can't do much >> >> without them. >> > >> > Sure, it doesn't expose

Re: [PATCH v16 00/23] selftests, powerpc, x86: Memory Protection Keys

* Dave Hansen: > Still doesn't build for me: > >> # make >> make --no-builtin-rules ARCH=x86_64 -C ../../../.. headers_install >> make[1]: Entering directory '/home/dave/linux.git' >> INSTALL ./usr/include >> make[1]: Leaving directory '/home/dave/linux.git' >> make: *** No rule to make target

Re: powerpc Linux scv support and scv system call ABI proposal

* Segher Boessenkool: > On Tue, Jan 28, 2020 at 05:04:49PM +0100, Florian Weimer wrote: >> * Segher Boessenkool: >> >> >> > I don't think we can save LR in a regular register around the system >> >> > call, explicitly in the inline asm statement, bec

Re: powerpc Linux scv support and scv system call ABI proposal

* Segher Boessenkool: > On Wed, Jan 29, 2020 at 06:02:34PM +0100, Florian Weimer wrote: >> * Segher Boessenkool: >> >> > On Wed, Jan 29, 2020 at 05:19:19PM +0100, Florian Weimer wrote: >> >> * Segher Boessenkool: >> >> >> But GCC doesn't e

Re: powerpc Linux scv support and scv system call ABI proposal

* Segher Boessenkool: >> I *assumed* that I would still get >> the value of r0 (the register) from the associated extended asm in this >> expression, even if it may now be a different register. Your comment >> made me think that this is undefined. > > Please show full(er) examples, I think we

Re: powerpc Linux scv support and scv system call ABI proposal

* Segher Boessenkool: >> > I don't think we can save LR in a regular register around the system >> > call, explicitly in the inline asm statement, because we still have to >> > generate proper unwinding information using CFI directives, something >> > that you cannot do from within the asm

Re: powerpc Linux scv support and scv system call ABI proposal

* Nicholas Piggin: > That gets the LR save/restore right when we're also using r0. Yes, I agree it looks good. Nice. >> But the kernel uses the -errno convention internally, so I think it >> would make sense to pass this to userspace and not convert back and >> forth. This would align with

Re: powerpc Linux scv support and scv system call ABI proposal

* Nicholas Piggin: > * Proposal is for PPC_FEATURE2_SCV to indicate 'scv 0' support, all other > vectors will return -ENOSYS, and the decision for how to add support for > a new vector deferred until we see the next user. Seems reasonable. We don't have to decide this today. > * Proposal

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

* Rich Felker: > My preference would be that it work just like the i386 AT_SYSINFO > where you just replace "int $128" with "call *%%gs:16" and the kernel > provides a stub in the vdso that performs either scv or the old > mechanism with the same calling convention. The i386 mechanism has

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

* Rich Felker: > On Thu, Apr 16, 2020 at 06:42:32PM +0200, Florian Weimer wrote: >> * Rich Felker: >> >> > On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote: >> >> * Rich Felker: >> >> >> >> > My preference would be th

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

* Rich Felker: > On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote: >> * Rich Felker: >> >> > My preference would be that it work just like the i386 AT_SYSINFO >> > where you just replace "int $128" with "call *%%gs:16" and the

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

* Nicholas Piggin via Libc-alpha: > We may or may not be getting a new ABI that will use instructions not > supported by old processors. > > https://sourceware.org/legacy-ml/binutils/2019-05/msg00331.html > > Current ABI continues to work of course and be the default for some > time, but

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

* Szabolcs Nagy: > * Nicholas Piggin [2020-04-20 12:08:36 +1000]: >> Excerpts from Rich Felker's message of April 20, 2020 11:29 am: >> > Also, allowing patching of executable pages is generally frowned upon >> > these days because W^X is a desirable hardening property. >> >> Right, it would

Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2

* Segher Boessenkool: > On Thu, Apr 16, 2020 at 08:34:42PM -0400, Rich Felker wrote: >> On Thu, Apr 16, 2020 at 06:02:35PM -0500, Segher Boessenkool wrote: >> > On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote: >> > > > I think my choice would

Re: [musl] Re: Powerpc Linux 'scv' system call ABI proposal take 2

* Nicholas Piggin: > Another option would be to use a different signal. I don't see that any > are more suitable. SIGSYS comes to my mind. But I don't know how exclusively it is associated with seccomp these days.

Re: [musl] Re: Powerpc Linux 'scv' system call ABI proposal take 2

* Nicholas Piggin: > So I would be disinclined to use SIGSYS unless there are no other better > signal types, and we don't want to use SIGILL for some good reason -- is > there a good reason to add complexity for userspace by differentiating > these two situations? No, SIGILL seems fine to

Re: [PATCH 2/2] selftests: vm: pkeys: Fix powerpc access right updates

* Sandipan Das: > The Power ISA mandates that all writes to the Authority > Mask Register (AMR) must always be preceded as well as > succeeded by a context-synchronizing instruction. This > applies to both the privileged and unprivileged variants > of the Move To AMR instruction. Ugh. Do you

Re: [PATCH 2/2] selftests: vm: pkeys: Fix powerpc access right updates

* Sandipan Das: > Hi Florian, > > On 08/05/20 11:31 pm, Florian Weimer wrote: >> * Sandipan Das: >> >>> The Power ISA mandates that all writes to the Authority >>> Mask Register (AMR) must always be preceded as well as >>> succeeded by a con

Re: Add a new fchmodat4() syscall, v2

* Palmer Dabbelt: > This patch set adds fchmodat4(), a new syscall. The actual > implementation is super simple: essentially it's just the same as > fchmodat(), but LOOKUP_FOLLOW is conditionally set based on the flags. > I've attempted to make this match "man 2 fchmodat" as closely as >

Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline

* Nicholas Piggin: > diff --git a/arch/powerpc/kernel/vdso64/sigtramp.S > b/arch/powerpc/kernel/vdso64/sigtramp.S > index a8cc0409d7d2..bbf68cd01088 100644 > --- a/arch/powerpc/kernel/vdso64/sigtramp.S > +++ b/arch/powerpc/kernel/vdso64/sigtramp.S > @@ -6,6 +6,7 @@ > * Copyright (C) 2004

  1   2   >