Re: [PATCH v2 1/6] aarch64: Fix missing BTI protection from dependencies [BZ #26926]

The 12/10/2020 14:51, Adhemerval Zanella wrote: > On 27/11/2020 10:19, Szabolcs Nagy via Libc-alpha wrote: > > The _dl_open_check and _rtld_main_check hooks are not called on the > > dependencies of a loaded module, so BTI protection was missed on > > every module other tha

Re: [PATCH v2 3/6] elf: Fix failure handling in _dl_map_object_from_fd

The 12/10/2020 15:25, Adhemerval Zanella wrote: > On 27/11/2020 10:20, Szabolcs Nagy via Libc-alpha wrote: > > There are many failure paths that call lose to do local cleanups > > in _dl_map_object_from_fd, but it did not clean everything. > > > > Handle l_phdr, l_

Re: [PATCH v2 0/6] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]

The 12/03/2020 17:30, Catalin Marinas wrote: > On Fri, Nov 27, 2020 at 01:19:16PM +0000, Szabolcs Nagy wrote: > > This is v2 of > > https://sourceware.org/pipermail/libc-alpha/2020-November/119305.html > > > > To enable BTI support, re-mmap executable segments inst

[PATCH v3 2/2] aarch64: Use mmap to add PROT_BTI instead of mprotect [BZ #26831]

Re-mmap executable segments if possible instead of using mprotect to add PROT_BTI. This allows using BTI protection with security policies that prevent mprotect with PROT_EXEC. If the fd of the ELF module is not available because it was kernel mapped then mprotect is used and failures are

[PATCH v3 1/2] aarch64: align address for BTI protection [BZ #26988]

Handle unaligned executable load segments (the bfd linker is not expected to produce such binaries, but other linkers may). Computing the mapping bounds follows _dl_map_object_from_fd more closely now. Fixes bug 26988. --- v3: - split the last patch in two so this bug is fixed separately. -

Re: [PATCH v2 0/6] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]

The 11/27/2020 13:19, Szabolcs Nagy via Libc-alpha wrote: > This is v2 of > https://sourceware.org/pipermail/libc-alpha/2020-November/119305.html > > To enable BTI support, re-mmap executable segments instead of > mprotecting them in case mprotect is seccomp filtered. > &g

[PATCH v2 6/6] aarch64: Use mmap to add PROT_BTI instead of mprotect [BZ #26831]

Re-mmap executable segments if possible instead of using mprotect to add PROT_BTI. This allows using BTI protection with security policies that prevent mprotect with PROT_EXEC. If the fd of the ELF module is not available because it was kernel mapped then mprotect is used and failures are

[PATCH v2 5/6] elf: Pass the fd to note processing

To handle GNU property notes on aarch64 some segments need to be mmaped again, so the fd of the loaded ELF module is needed. When the fd is not available (kernel loaded modules), then -1 is passed. The fd is passed to both _dl_process_pt_gnu_property and _dl_process_pt_note for consistency.

[PATCH v2 4/6] elf: Move note processing after l_phdr is updated

Program headers are processed in two pass: after the first pass load segments are mmapped so in the second pass target specific note processing logic can access the notes. The second pass is moved later so various link_map fields are set up that may be useful for note processing such as l_phdr.

[PATCH v2 3/6] elf: Fix failure handling in _dl_map_object_from_fd

There are many failure paths that call lose to do local cleanups in _dl_map_object_from_fd, but it did not clean everything. Handle l_phdr, l_libname and mapped segments in the common failure handling code. There are various bits that may not be cleaned properly on failure (e.g. executable

[PATCH v2 1/6] aarch64: Fix missing BTI protection from dependencies [BZ #26926]

The _dl_open_check and _rtld_main_check hooks are not called on the dependencies of a loaded module, so BTI protection was missed on every module other than the main executable and directly dlopened libraries. The fix just iterates over dependencies to enable BTI. Fixes bug 26926. ---

[PATCH v2 2/6] elf: lose is closely tied to _dl_map_object_from_fd

Simple refactoring to keep failure handling next to _dl_map_object_from_fd. --- elf/dl-load.c | 48 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/elf/dl-load.c b/elf/dl-load.c index f3201e7c14..21e55deb19 100644 ---

[PATCH v2 0/6] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]

4/6]: Move the note handling to a different place (after l_phdr setup, but before fd is closed). - [5/6]: Rebased. - [6/6]: First record errors and only report them later. (this fixes various failure handling issues.) Szabolcs Nagy (6): aarch64: Fix missing BTI protection from dependencies

Re: [PATCH 0/4] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]

The 11/04/2020 09:20, Will Deacon wrote: > On Tue, Nov 03, 2020 at 05:34:38PM +, Mark Brown wrote: > > On Tue, Nov 03, 2020 at 10:25:37AM +, Szabolcs Nagy wrote: > > > > > Re-mmap executable segments instead of mprotecting them in > > >

Re: [PATCH 0/4] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]

The 11/04/2020 17:19, Topi Miettinen wrote: > On 4.11.2020 16.35, Catalin Marinas wrote: > > On Wed, Nov 04, 2020 at 11:55:57AM +0200, Topi Miettinen wrote: > > > On 4.11.2020 11.29, Florian Weimer wrote: > > > > * Will Deacon: > > > > > Is there real value in this seccomp filter if it only looks

Re: [PATCH 0/4] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]

The 11/03/2020 23:41, Jeremy Linton wrote: > On 11/3/20 11:34 AM, Mark Brown wrote: > > On Tue, Nov 03, 2020 at 10:25:37AM +, Szabolcs Nagy wrote: > > > > > Re-mmap executable segments instead of mprotecting them in > > > case mprotect is seccomp filtered.

Re: [PATCH 2/4] elf: Move note processing after l_phdr is updated [BZ #26831]

The 11/03/2020 04:36, H.J. Lu wrote: > On Tue, Nov 3, 2020 at 2:38 AM Florian Weimer wrote: > > * Szabolcs Nagy: > > > > > Program headers are processed in two pass: after the first pass > > > load segments are mmapped so in the second pass target specific >

[PATCH 4/4] aarch64: Remove the bti link_map field [BZ #26831]

The bti link_map field is no longer necessary because PROT_BTI is applied at note processing time immediately instead of in _dl_open_check based on the bti field. This is a separate patch that is not expected to be backported to avoid changing the link_map layout that is libc internal ABI. ---

[PATCH 3/4] aarch64: Use mmap to add PROT_BTI instead of mprotect [BZ #26831]

Re-mmap executable segments if possible instead of using mprotect to add PROT_BTI. This allows using BTI protection with security policies that prevent mprotect with PROT_EXEC. If the fd of the ELF module is not available because it was kernel mapped then mprotect is used and failures are

[PATCH 2/4] elf: Move note processing after l_phdr is updated [BZ #26831]

Program headers are processed in two pass: after the first pass load segments are mmapped so in the second pass target specific note processing logic can access the notes. The second pass is moved later so various link_map fields are set up that may be useful for note processing such as l_phdr.

[PATCH 1/4] elf: Pass the fd to note processing [BZ #26831]

To handle GNU property notes on aarch64 some segments need to be mmaped again, so the fd of the loaded ELF module is needed. When the fd is not available (kernel loaded modules), then -1 is passed. The fd is passed to both _dl_process_pt_gnu_property and _dl_process_pt_note for consistency.

[PATCH 0/4] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]

protection at runtime based on user space policy so it is better if the kernel maps BTI compatible binaries with PROT_BTI by default.) Szabolcs Nagy (4): elf: Pass the fd to note processing [BZ #26831] elf: Move note processing after l_phdr is updated [BZ #26831] aarch64: Use mmap to add PROT_BTI

Re: BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote: > Unrolling this discussion a bit, this problem comes from a few sources: > > 1) systemd is trying to implement a policy that doesn't fit SECCOMP > syscall filtering very well. > > 2) The program is trying to do something not expressible

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

The 10/22/2020 10:31, Catalin Marinas wrote: > IIUC, the problem is with the main executable which is mapped by the > kernel without PROT_BTI. The dynamic loader wants to set PROT_BTI but > does not have the original file descriptor to be able to remap. Its only > choice is mprotect() and this

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

The 10/22/2020 11:17, Topi Miettinen via Libc-alpha wrote: > On 22.10.2020 10.54, Florian Weimer wrote: > > * Lennart Poettering: > > > Did you see Topi's comments on the systemd issue? > > > > > > https://github.com/systemd/systemd/issues/17368#issuecomment-710485532 > > > > > > I think I agree

Re: [systemd-devel] BTI interaction between seccomp filters in systemd and glibc mprotect calls, causing service failures

The 10/22/2020 09:18, Lennart Poettering wrote: > On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote: > > > Hi, > > > > There is a problem with glibc+systemd on BTI enabled systems. Systemd > > has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny > > PROT_EXEC

Re: [PATCH v2] module: Harden STRICT_MODULE_RWX

The 08/12/2020 18:37, Ard Biesheuvel wrote: > module_frob_arch_sections > > On Wed, 12 Aug 2020 at 18:00, Jessica Yu wrote: > > > > +++ Szabolcs Nagy [12/08/20 15:15 +0100]: > > >The 08/12/2020 13:56, Will Deacon wrote: > > >> On Wed, Aug 12, 2020 at 12

Re: [PATCH v2] module: Harden STRICT_MODULE_RWX

The 08/12/2020 13:56, Will Deacon wrote: > On Wed, Aug 12, 2020 at 12:40:05PM +0200, pet...@infradead.org wrote: > > On Wed, Aug 12, 2020 at 10:56:56AM +0200, Ard Biesheuvel wrote: > > > The module .lds has BYTE(0) in the section contents to prevent the > > > linker from pruning them entirely. The

Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)

The 06/11/2020 20:26, Joseph Myers wrote: > On Thu, 11 Jun 2020, Mathieu Desnoyers wrote: > > I managed to get a repository up and running for librseq, and have > > integrated > > the rseq.2 man page with comments from Michael Kerrisk here: > > > >

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

* Kyle Evans [2020-06-05 21:54:56 -0500]: > On Fri, Jun 5, 2020 at 9:55 AM Szabolcs Nagy wrote: > > this api needs a documentation patch if there isn't yet. > > > > currently there is no libc interface contract in place that > > says which calls may use libc

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

* Christian Brauner [2020-06-02 22:42:17 +0200]: > This adds the close_range() syscall. It allows to efficiently close a range > of file descriptors up to all file descriptors of a calling task. > > I've also coordinated with some FreeBSD developers who got in touch with > me (Cced below).

Re: sys/sysinfo.h clash with linux/kernel.h

i think the linux-api list is the right place for this so adding it on cc. * Rich Felker [2020-06-02 17:37:05 -0400]: > linux/kernel.h is a uapi header that does almost nothing but define > some internal-use alignment macros and -- oddly -- include > linux/sysinfo.h to provide a definition of

Re: clock_gettime64 vdso bug on 32-bit arm, rpi-4

The 05/19/2020 22:31, Arnd Bergmann wrote: > On Tue, May 19, 2020 at 10:24 PM Adhemerval Zanella > wrote: > > On 19/05/2020 16:54, Arnd Bergmann wrote: > > > Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso call > > > last > > > month:

Re: [PATCH] ARM: pass -msoft-float to gcc earlier

The 05/19/2020 17:38, Nick Desaulniers wrote: > sorry, hit tab/enter too soon... > > On Tue, May 19, 2020 at 5:37 PM Nick Desaulniers > wrote: > > > > On Tue, May 19, 2020 at 3:09 PM Arnd Bergmann wrote: > > > > > > Szabolcs Nagy ran into a kernel buil

Re: [PATCH glibc 5/9] glibc: Perform rseq(2) registration at C startup and thread creation (v17)

The 04/29/2020 10:18, Florian Weimer wrote: > * Szabolcs Nagy: > > > The 04/28/2020 10:58, Mathieu Desnoyers wrote: > >> - On Apr 28, 2020, at 8:54 AM, Florian Weimer f...@deneb.enyo.de wrote: > >> > That one definitely should work. > >> > > &

Re: [PATCH glibc 5/9] glibc: Perform rseq(2) registration at C startup and thread creation (v17)

The 04/28/2020 10:58, Mathieu Desnoyers wrote: > - On Apr 28, 2020, at 8:54 AM, Florian Weimer f...@deneb.enyo.de wrote: > > That one definitely should work. > > > > I expect you might see this if libgcc_s.so.1 is installed into a > > multiarch subdirectory that upstream glibc does not

Re: [PATCH glibc] Linux: Include in under __USE_MISC

On 22/07/2019 14:44, Florian Weimer wrote: > * Szabolcs Nagy: > >> (note: in musl these ioctl macros are in sys/ioctl.h >> which is not a posix header so namespace rules are >> less strict than for sys/socket.h and users tend to >> include it for ioctl()) >

Re: [PATCH glibc] Linux: Include in under __USE_MISC

On 22/07/2019 12:34, Arnd Bergmann wrote: > On Mon, Jul 22, 2019 at 1:31 PM Florian Weimer wrote: >> >> Historically, (which is included from ) >> provided ioctl operations for sockets. User code accessed them >> through . The kernel UAPI headers have removed these >> definitions in favor of .

Re: [PATCH v4 1/2] arm64: Define Documentation/arm64/tagged-address-abi.txt

On 13/06/2019 15:03, Vincenzo Frascino wrote: > On 13/06/2019 13:28, Szabolcs Nagy wrote: >> On 13/06/2019 12:16, Vincenzo Frascino wrote: >>> On 13/06/2019 11:14, Szabolcs Nagy wrote: >>>> On 13/06/2019 10:20, Catalin Marinas wrote: >>>>> On Wed, Ju

Re: [PATCH v1 1/2] fork: add clone3

* Christian Brauner [2019-05-29 17:22:36 +0200]: > This adds the clone3 system call. > > As mentioned several times already (cf. [7], [8]) here's the promised > patchset for clone3(). > > We recently merged the CLONE_PIDFD patchset (cf. [1]). It took the last > free flag from clone(). > >

Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v9)

On 22/04/2019 18:56, Mathieu Desnoyers wrote: > diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/rseq.h > b/sysdeps/unix/sysv/linux/aarch64/bits/rseq.h > new file mode 100644 > index 00..e538668612 > --- /dev/null > +++ b/sysdeps/unix/sysv/linux/aarch64/bits/rseq.h > @@ -0,0 +1,44 @@ >

Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)

On 18/04/2019 19:17, Mathieu Desnoyers wrote: > - On Apr 18, 2019, at 1:37 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote: >> you have to add a documentation comment somewhere >> explaining if RSEQ_SIG is the value that's passed to >> the kernel and then aarch64 asm code h

Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)

On 18/04/2019 18:10, Mathieu Desnoyers wrote: > > - On Apr 18, 2019, at 12:07 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote: > >> On 18/04/2019 16:41, Mathieu Desnoyers wrote: >>> - On Apr 18, 2019, at 11:33 AM, Szabolcs Nagy szabolcs.n...@arm.com >>> wr

Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)

On 18/04/2019 16:41, Mathieu Desnoyers wrote: > - On Apr 18, 2019, at 11:33 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote: > >> On 18/04/2019 14:17, Mathieu Desnoyers wrote: >>> - On Apr 17, 2019, at 3:56 PM, Mathieu Desnoyers >>> mathieu.desnoy...@efficios.c

Re: [PATCH 2/5] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux (v2)

On 16/04/2019 18:32, Mathieu Desnoyers wrote: > --- a/sysdeps/unix/sysv/linux/sched_getcpu.c > +++ b/sysdeps/unix/sysv/linux/sched_getcpu.c > @@ -37,3 +37,26 @@ sched_getcpu (void) >return -1; > #endif > } > + > +#ifdef __NR_rseq > +#include > +#endif > + > +#if defined __NR_rseq && defined

Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8)

On 18/04/2019 14:17, Mathieu Desnoyers wrote: > - On Apr 17, 2019, at 3:56 PM, Mathieu Desnoyers > mathieu.desnoy...@efficios.com wrote: >> - On Apr 17, 2019, at 12:17 PM, Joseph Myers jos...@codesourcery.com >> wrote: >>> On Wed, 17 Apr 2019, Mathieu Desnoyers wrote: >>> > +/*

Re: [RFC][PATCH 0/3] arm64 relaxed ABI

On 25/02/2019 16:57, Catalin Marinas wrote: > On Tue, Feb 19, 2019 at 06:38:31PM +0000, Szabolcs Nagy wrote: >> i think these rules work for the cases i care about, a more >> tricky question is when/how to check for the new syscall abi >> and when/how the TCR_EL1.TBI0 sett

Re: [PATCH v10 00/12] arm64: untag user pointers passed to the kernel

On 22/02/2019 15:40, Andrey Konovalov wrote: > On Fri, Feb 22, 2019 at 4:35 PM Szabolcs Nagy wrote: >> >> On 22/02/2019 12:53, Andrey Konovalov wrote: >>> This patchset is meant to be merged together with "arm64 relaxed ABI" [1]. >>> >>> arm6

Re: [PATCH v10 00/12] arm64: untag user pointers passed to the kernel

On 22/02/2019 12:53, Andrey Konovalov wrote: > This patchset is meant to be merged together with "arm64 relaxed ABI" [1]. > > arm64 has a feature called Top Byte Ignore, which allows to embed pointer > tags into the top byte of each pointer. Userspace programs (such as > HWASan, a memory

Re: [RFC][PATCH 0/3] arm64 relaxed ABI

On 12/02/2019 18:02, Catalin Marinas wrote: > On Mon, Feb 11, 2019 at 12:32:55PM -0800, Evgenii Stepanov wrote: >> On Mon, Feb 11, 2019 at 9:28 AM Kevin Brodsky wrote: >>> On 19/12/2018 12:52, Dave Martin wrote: Really, the kernel should do the expected thing with all "non-weird"

Re: [PATCH 3/3] arm64/sve: Disentangle from

On 19/12/2018 15:23, Dave Martin wrote: > On Wed, Dec 19, 2018 at 03:11:52PM +0000, Szabolcs Nagy wrote: >> On 18/12/2018 12:14, Dave Martin wrote: >>> On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote: > > [...] > >>>>>> ./

Re: [PATCH 3/3] arm64/sve: Disentangle from

On 18/12/2018 12:14, Dave Martin wrote: > On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote: >> Hi Dave, >> >> Thank you for the patch! Perhaps something to improve: >> >> [auto build test WARNING on arm64/for-next/core] >> [also build test WARNING on v4.20-rc6 next-20181214] >>

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

On 14/12/2018 18:25, Dave Martin wrote: > On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote: >> On 11/12/2018 19:26, Dave Martin wrote: >>> This patch refactors the UAPI header definitions for the Arm SVE >>> extension to avoid multiple-definition proble

Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h

On 11/12/2018 19:26, Dave Martin wrote: > This patch refactors the UAPI header definitions for the Arm SVE > extension to avoid multiple-definition problems when userspace mixes its > own sigcontext.h definitions with the kernel's ptrace.h (which is > apparently routine). > > A common backend

Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

On 23/11/18 21:09, Mathieu Desnoyers wrote: > - On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote: > >> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote: >>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote: >>> On Fri, Nov 23, 2018 at

Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

On 23/11/18 21:09, Mathieu Desnoyers wrote: > - On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote: > >> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote: >>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote: >>> On Fri, Nov 23, 2018 at

Re: Official Linux system wrapper library?

On 23/11/18 14:11, David Newall wrote: > On 24/11/18 12:04 am, Florian Weimer wrote: >> But socketcall does not exist on all architectures.  Neither does >> getpid, it's called getxpid on some architectures. >> ... >> I think it would be a poor approach to expose application developers to >> these

Re: Official Linux system wrapper library?

On 23/11/18 14:11, David Newall wrote: > On 24/11/18 12:04 am, Florian Weimer wrote: >> But socketcall does not exist on all architectures.  Neither does >> getpid, it's called getxpid on some architectures. >> ... >> I think it would be a poor approach to expose application developers to >> these

Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

On 22/11/18 15:33, Mathieu Desnoyers wrote: > - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote: >> Right, but in case of user-supplied stacks, we actually free TLS memory >> at this point, so signals need to be blocked because the TCB is >> (partially) gone after that. >

Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

On 22/11/18 15:33, Mathieu Desnoyers wrote: > - On Nov 22, 2018, at 10:21 AM, Florian Weimer fwei...@redhat.com wrote: >> Right, but in case of user-supplied stacks, we actually free TLS memory >> at this point, so signals need to be blocked because the TCB is >> (partially) gone after that. >

Re: Official Linux system wrapper library?

On 13/11/18 19:39, Dave Martin wrote: > On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote: >> We should adopt a similar approach. Shipping a lower-level >> "liblinux.so" tightly bound to the kernel would not only let the >> kernel bypass glibc's "editorial discretion" in exposing

Re: Official Linux system wrapper library?

On 13/11/18 19:39, Dave Martin wrote: > On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote: >> We should adopt a similar approach. Shipping a lower-level >> "liblinux.so" tightly bound to the kernel would not only let the >> kernel bypass glibc's "editorial discretion" in exposing

Re: Official Linux system wrapper library?

On 11/11/18 14:22, Daniel Colascione wrote: > On Sun, Nov 11, 2018 at 3:09 AM, Florian Weimer wrote: >> We had a patch for the membarrier system call, but the kernel developers >> could not tell us what the system call does in therms of the C/C++ >> memory model > [snip] >> A lot of the new

Re: Official Linux system wrapper library?

On 11/11/18 14:22, Daniel Colascione wrote: > On Sun, Nov 11, 2018 at 3:09 AM, Florian Weimer wrote: >> We had a patch for the membarrier system call, but the kernel developers >> could not tell us what the system call does in therms of the C/C++ >> memory model > [snip] >> A lot of the new

Re: [RFC PATCH for 4.21 01/16] rseq/selftests: Add reference counter to coexist with glibc

On 11/10/18 20:42, Mathieu Desnoyers wrote: > - On Oct 11, 2018, at 1:04 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote: > >> On 11/10/18 17:37, Mathieu Desnoyers wrote: >>> - On Oct 11, 2018, at 12:20 PM, Szabolcs Nagy szabolcs.n...@arm.com >>> wrote: &

Re: [RFC PATCH for 4.21 01/16] rseq/selftests: Add reference counter to coexist with glibc

On 11/10/18 20:42, Mathieu Desnoyers wrote: > - On Oct 11, 2018, at 1:04 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote: > >> On 11/10/18 17:37, Mathieu Desnoyers wrote: >>> - On Oct 11, 2018, at 12:20 PM, Szabolcs Nagy szabolcs.n...@arm.com >>> wrote: &

Re: [RFC PATCH for 4.21 01/16] rseq/selftests: Add reference counter to coexist with glibc

On 11/10/18 17:37, Mathieu Desnoyers wrote: > - On Oct 11, 2018, at 12:20 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote: >> On 11/10/18 16:13, Mathieu Desnoyers wrote: >>> - On Oct 11, 2018, at 6:37 AM, Szabolcs Nagy szabolcs.n...@arm.com >>> wrote: >

Re: [RFC PATCH for 4.21 01/16] rseq/selftests: Add reference counter to coexist with glibc

On 11/10/18 17:37, Mathieu Desnoyers wrote: > - On Oct 11, 2018, at 12:20 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote: >> On 11/10/18 16:13, Mathieu Desnoyers wrote: >>> - On Oct 11, 2018, at 6:37 AM, Szabolcs Nagy szabolcs.n...@arm.com >>> wrote: >

Re: [RFC PATCH for 4.21 01/16] rseq/selftests: Add reference counter to coexist with glibc

On 11/10/18 16:13, Mathieu Desnoyers wrote: > - On Oct 11, 2018, at 6:37 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote: > >> On 10/10/18 20:19, Mathieu Desnoyers wrote: >>> In order to integrate rseq into user-space applications, add a reference >>> counter field

Re: [RFC PATCH for 4.21 01/16] rseq/selftests: Add reference counter to coexist with glibc

On 11/10/18 16:13, Mathieu Desnoyers wrote: > - On Oct 11, 2018, at 6:37 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote: > >> On 10/10/18 20:19, Mathieu Desnoyers wrote: >>> In order to integrate rseq into user-space applications, add a reference >>> counter field

Re: [RFC PATCH for 4.21 01/16] rseq/selftests: Add reference counter to coexist with glibc

On 10/10/18 20:19, Mathieu Desnoyers wrote: > In order to integrate rseq into user-space applications, add a reference > counter field after the struct rseq TLS ABI so many rseq users can be > linked into the same application (e.g. librseq and glibc). The > reference count ensures that rseq

Re: [RFC PATCH for 4.21 01/16] rseq/selftests: Add reference counter to coexist with glibc

On 10/10/18 20:19, Mathieu Desnoyers wrote: > In order to integrate rseq into user-space applications, add a reference > counter field after the struct rseq TLS ABI so many rseq users can be > linked into the same application (e.g. librseq and glibc). The > reference count ensures that rseq

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On 19/09/18 22:01, Mathieu Desnoyers wrote: - On Sep 19, 2018, at 1:38 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote: note that libpthread.so is built with -ftls-model=initial-exec Which would indeed make these annotations redundant. I'll remove them. (and if it wasn't then you'd want

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On 19/09/18 22:01, Mathieu Desnoyers wrote: - On Sep 19, 2018, at 1:38 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote: note that libpthread.so is built with -ftls-model=initial-exec Which would indeed make these annotations redundant. I'll remove them. (and if it wasn't then you'd want

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On 19/09/18 15:44, Mathieu Desnoyers wrote: Things to consider: - Move __rseq_refcount to an extra field at the end of __rseq_abi to eliminate one symbol. This would require to wrap struct rseq into e.g. struct rseq_lib or such, e.g.: struct rseq_lib { struct rseq kabi; int

Re: [RFC PATCH] glibc: Perform rseq(2) registration at nptl init and thread creation

On 19/09/18 15:44, Mathieu Desnoyers wrote: Things to consider: - Move __rseq_refcount to an extra field at the end of __rseq_abi to eliminate one symbol. This would require to wrap struct rseq into e.g. struct rseq_lib or such, e.g.: struct rseq_lib { struct rseq kabi; int

Re: framebuffer corruption due to overlapping stp instructions on arm64

On 03/08/18 08:53, Florian Weimer wrote: On 08/03/2018 09:11 AM, Andrew Pinski wrote: Yes fix Links not to use memcpy on the framebuffer. It is undefined behavior to use device memory with memcpy. Some (de facto) ABIs require that it is supported, though.  For example, the POWER string

Re: framebuffer corruption due to overlapping stp instructions on arm64

On 03/08/18 08:53, Florian Weimer wrote: On 08/03/2018 09:11 AM, Andrew Pinski wrote: Yes fix Links not to use memcpy on the framebuffer. It is undefined behavior to use device memory with memcpy. Some (de facto) ABIs require that it is supported, though.  For example, the POWER string

Re: [(resend)] seq_file: reset iterator to first record for zero offset

* Miklos Szeredi [2016-12-19 12:38:00 +0100]: > Al, > > Can you please take (or NACK) this patch please? > > Thanks, > Miklos > --- > From: Tomasz Majchrzak > Date: Tue, 29 Nov 2016 15:18:20 +0100 > > If kernfs file is empty on a first read,

Re: [(resend)] seq_file: reset iterator to first record for zero offset

* Miklos Szeredi [2016-12-19 12:38:00 +0100]: > Al, > > Can you please take (or NACK) this patch please? > > Thanks, > Miklos > --- > From: Tomasz Majchrzak > Date: Tue, 29 Nov 2016 15:18:20 +0100 > > If kernfs file is empty on a first read, successive read operations > using the same file

Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

* Carlos O'Donell [2017-03-08 10:53:00 -0500]: > On 11/11/2016 07:08 AM, Felix Janda wrote: > > fixes the following compiler errors when is included > > after musl : > > > > ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr' > > ./linux/in6.h:49:8: error:

Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

* Carlos O'Donell [2017-03-08 10:53:00 -0500]: > On 11/11/2016 07:08 AM, Felix Janda wrote: > > fixes the following compiler errors when is included > > after musl : > > > > ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr' > > ./linux/in6.h:49:8: error: redefinition of 'struct

Re: Formal description of system call interface

* Dmitry Vyukov <dvyu...@google.com> [2016-11-21 16:03:04 +0100]: > On Mon, Nov 7, 2016 at 1:28 AM, Szabolcs Nagy <n...@port70.net> wrote: > > * Dmitry Vyukov <dvyu...@google.com> [2016-11-06 14:39:28 -0800]: > >> For the reference, current syzkaller descriptio

Re: Formal description of system call interface

* Dmitry Vyukov [2016-11-21 16:03:04 +0100]: > On Mon, Nov 7, 2016 at 1:28 AM, Szabolcs Nagy wrote: > > * Dmitry Vyukov [2016-11-06 14:39:28 -0800]: > >> For the reference, current syzkaller descriptions are in txt files here: > >> https://github.com/googl

Re: Formal description of system call interface

* Dmitry Vyukov [2016-11-06 14:39:28 -0800]: > This is notes from the discussion we had at Linux Plumbers this week > regarding providing a formal description of system calls (user API). yes a database of the syscall abis would be useful ..depending on the level of detail it

Re: Formal description of system call interface

* Dmitry Vyukov [2016-11-06 14:39:28 -0800]: > This is notes from the discussion we had at Linux Plumbers this week > regarding providing a formal description of system calls (user API). yes a database of the syscall abis would be useful ..depending on the level of detail it has. (right now

Re: [RFC PATCH 00/27] ARM64: support ILP32

On 21/06/16 06:06, Yury Norov wrote: > This series enables aarch64 port with ilp32 mode. > > After long discussions in kernel list, we finally got > consensus on how ABI should look. This patchset adds > support for the ABI in GLIBC. It is tested with LTP > with no big regressions comparing to

Re: [RFC PATCH 00/27] ARM64: support ILP32

On 21/06/16 06:06, Yury Norov wrote: > This series enables aarch64 port with ilp32 mode. > > After long discussions in kernel list, we finally got > consensus on how ABI should look. This patchset adds > support for the ABI in GLIBC. It is tested with LTP > with no big regressions comparing to

Re: [PATCH 02/27] [AARCH64] Add header guards to sysdep.h headers.

On 21/06/16 06:06, Yury Norov wrote: > From: Andrew Pinski > > * sysdeps/aarch64/sysdep.h: Add header guards. > the things listed below are not part of the patch (upstream glibc already has these fixes) > [AARCH64] Remove 64 from some relocation names as they have been

Re: [PATCH 02/27] [AARCH64] Add header guards to sysdep.h headers.

On 21/06/16 06:06, Yury Norov wrote: > From: Andrew Pinski > > * sysdeps/aarch64/sysdep.h: Add header guards. > the things listed below are not part of the patch (upstream glibc already has these fixes) > [AARCH64] Remove 64 from some relocation names as they have been renamed in > later

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On 21/06/16 06:06, Yury Norov wrote: > From: Andrew Pinski > > NOTE This is an ABI change for AARCH64. > If you have some AARCH32 and AARCH64 applications and they both use > utmp, one of them will fail due to the use of time_t inside the > utmp binary format. > > This fixes

Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

On 21/06/16 06:06, Yury Norov wrote: > From: Andrew Pinski > > NOTE This is an ABI change for AARCH64. > If you have some AARCH32 and AARCH64 applications and they both use > utmp, one of them will fail due to the use of time_t inside the > utmp binary format. > > This fixes the problem by

Re: [PATCH v6 00/21] ILP32 for ARM64

On 02/06/16 20:03, Yury Norov wrote: > On Tue, May 24, 2016 at 03:04:29AM +0300, Yury Norov wrote: >> ILP32 glibc branch is available here: >> https://github.com/norov/glibc/tree/ilp32-2.23 >> > > So for AARCH64/ILP32 we turn next types to 64-bit in glibc: > #define __INO_T_TYPE

Re: [PATCH v6 00/21] ILP32 for ARM64

On 02/06/16 20:03, Yury Norov wrote: > On Tue, May 24, 2016 at 03:04:29AM +0300, Yury Norov wrote: >> ILP32 glibc branch is available here: >> https://github.com/norov/glibc/tree/ilp32-2.23 >> > > So for AARCH64/ILP32 we turn next types to 64-bit in glibc: > #define __INO_T_TYPE

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On 26/05/16 15:20, Catalin Marinas wrote: > While writing the above, I realised the current ILP32 patches still miss > on converting pointers passed from user space (unless I got myself > confused in macros). The new __SC_WRAP() and COMPAT_SYSCALL_WRAPx() > macros take care of zero or sign

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On 26/05/16 15:20, Catalin Marinas wrote: > While writing the above, I realised the current ILP32 patches still miss > on converting pointers passed from user space (unless I got myself > confused in macros). The new __SC_WRAP() and COMPAT_SYSCALL_WRAPx() > macros take care of zero or sign

Re: [PATCH v6 00/21] ILP32 for ARM64

On 24/05/16 01:04, Yury Norov wrote: > This version is based on kernel v4.6. > It works with glibc-2.23, and tested with LTP. > ... > ILP32 glibc branch is available here: > https://github.com/norov/glibc/tree/ilp32-2.23 > > It is tested with this series with no major downsides. I will send it

Re: [PATCH v6 00/21] ILP32 for ARM64

On 24/05/16 01:04, Yury Norov wrote: > This version is based on kernel v4.6. > It works with glibc-2.23, and tested with LTP. > ... > ILP32 glibc branch is available here: > https://github.com/norov/glibc/tree/ilp32-2.23 > > It is tested with this series with no major downsides. I will send it

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On 05/04/16 23:08, Yury Norov wrote: > This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem. > It works with updated glibc [1] (though very draft), and tested with LTP. > > It was tested on QEMU and ThunderX machines. No major difference found. > This is RFC because ILP32

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On 05/04/16 23:08, Yury Norov wrote: > This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem. > It works with updated glibc [1] (though very draft), and tested with LTP. > > It was tested on QEMU and ThunderX machines. No major difference found. > This is RFC because ILP32

  1   2   >