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

* Mathieu Desnoyers: > AFAIU, the only gain here would be to make sure we don't emit useless > ";" in the "/* nothing */" case. But does it matter ? I don't think C allows empty constructs like this at the top level. And something similar for _Alignas/attribute aligned, >>> >>> I don't see

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

* Mathieu Desnoyers: > Something like this ? > > #ifdef __cplusplus > # if __cplusplus >= 201103L > # define rseq_static_assert (expr, diagnostic) static_assert (expr, > diagnostic) > # define rseq_alignof alignof > # endif > #elif __STDC_VERSION__ >=

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

* Mathieu Desnoyers: > The larger question here is: considering that we re-implement the entire > uapi header within glibc (which includes the uptr addition), do we still > care about using the header provided by the Linux kernel ? We don't care, but our users do. Eventually, they want to

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

* Mathieu Desnoyers via Libc-alpha: > diff --git a/NEWS b/NEWS > index 141078c319..c4e0370fc4 100644 > --- a/NEWS > +++ b/NEWS > @@ -23,6 +23,16 @@ Major new features: >toolchains. It is recommended to use GCC 8 or newer when testing >this option. > > +* Support for automatically

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

* Mathieu Desnoyers via Libc-alpha: > diff --git a/sysdeps/unix/sysv/linux/sched_getcpu.c > b/sysdeps/unix/sysv/linux/sched_getcpu.c > index c019cfb3cf..2269c4f2bd 100644 > --- a/sysdeps/unix/sysv/linux/sched_getcpu.c > +++ b/sysdeps/unix/sysv/linux/sched_getcpu.c > @@ -18,10 +18,15 @@ >

Re: [PATCH] dns: Apply a default TTL to records obtained from getaddrinfo()

* David Howells: > Fix this to apply a default TTL of 10mins in the event that we haven't got > one. This can be configured in /etc/keyutils/key.dns_resolver.conf by > adding the line: > > default_ttl: > > to the file. If the name resolution is not needed continuously, but only for the

Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC)

* Kees Cook: > I think I misunderstood what you meant (Mickaël got me sorted out > now). If O_EXEC is already meant to be "EXEC and _not_ READ nor WRITE", > then yes, this new flag can't be O_EXEC. I was reading the glibc > documentation (which treats it as a permission bit flag, not POSIX, >

Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC)

* Kees Cook: > On Fri, May 15, 2020 at 10:43:34AM +0200, Florian Weimer wrote: >> * Kees Cook: >> >> > Maybe I've missed some earlier discussion that ruled this out, but I >> > couldn't find it: let's just add O_EXEC and be done with it. It actually >> >

Re: How about just O_EXEC? (was Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC)

* Kees Cook: > Maybe I've missed some earlier discussion that ruled this out, but I > couldn't find it: let's just add O_EXEC and be done with it. It actually > makes the execve() path more like openat2() and is much cleaner after > a little refactoring. Here are the results, though I haven't

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

* Mathieu Desnoyers: > If we go this way, I'd also recommend to treat any situation where > __rseq_abi.cpu_id is already initialized as a fatal error. Does the > code below seem OK to you ? > > static inline void > rseq_register_current_thread (void) > { > int ret; > > if (__rseq_abi.cpu_id

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

* Mathieu Desnoyers: > @deftypevar {struct rseq} __rseq_abi > @standards{Linux, sys/rseq.h} > @Theglibc{} implements a @code{__rseq_abi} TLS symbol to interact with the > Restartable Sequences system call (Linux-specific). The layout of this > structure is defined by the @file{sys/rseq.h}

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

* Mathieu Desnoyers: > diff --git a/NEWS b/NEWS > index 0e627b3405..0b85a02c12 100644 > --- a/NEWS > +++ b/NEWS > @@ -18,6 +18,16 @@ Major new features: > * The GNU C Library now loads audit modules listed in the DT_AUDIT and >DT_DEPAUDIT dynamic section entries of the main executable. > >

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

* Mathieu Desnoyers: > - On Apr 28, 2020, at 8:33 AM, Mathieu Desnoyers > mathieu.desnoy...@efficios.com wrote: > >> - On Apr 28, 2020, at 8:02 AM, Florian Weimer f...@deneb.enyo.de wrote: >> > [...] >>> >>>> x32 should not be an issue as

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

* 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. >> > >> > I expect you might see this if libgcc_s.so.1 is installe

Re: [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC

* Jann Horn: > Just as a comment: You'd probably also have to use RESOLVE_MAYEXEC in > the dynamic linker. Absolutely. In typical configurations, the kernel does not enforce that executable mappings must be backed by files which are executable. It's most obvious with using an explicit loader

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

* Mathieu Desnoyers: > - On Apr 28, 2020, at 8:35 AM, Florian Weimer f...@deneb.enyo.de wrote: > >> * Mathieu Desnoyers: >> >>> One issue I'm currently facing when running "make check": because >>> nptl/tst-rseq-nptl.c uses pthread_cancel(), I r

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

* Mathieu Desnoyers: > One issue I'm currently facing when running "make check": because > nptl/tst-rseq-nptl.c uses pthread_cancel(), I run into an Abort > with: > > libgcc_s.so.1 must be installed for pthread_cancel to work > Didn't expect signal from child: got `Aborted' This is really

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

* Mathieu Desnoyers: > +/* struct rseq is aligned on 4 * 8 bytes to ensure it is always > + contained within a single cache-line. > + > + A single struct rseq per thread is allowed. */ > +struct rseq > + { > +/* Restartable sequences cpu_id_start field.

Re: [PATCH] tracefs: Do not allocate and free proxy_ops for lockdown

* Steven Rostedt: > Once locked down is set, can it ever be undone without rebooting? I think this is the original intent with such patches, yes. But then reality interferes and people add some escape hatch, so that it's possible again to load arbitrary kernel modules. And for servers, you

Re: [PATCH 1/2] clone3: add CLONE3_CLEAR_SIGHAND

* Christian Brauner: > On Thu, Oct 10, 2019 at 04:19:44PM +0200, Florian Weimer wrote: >> * Christian Brauner: >> >> > @@ -2567,7 +2572,7 @@ static bool clone3_args_valid(const struct >> > kernel_clone_args *kargs) >> > * All lower bits of

Re: [PATCH 1/2] clone3: add CLONE3_CLEAR_SIGHAND

* Christian Brauner: > @@ -2567,7 +2572,7 @@ static bool clone3_args_valid(const struct > kernel_clone_args *kargs) >* All lower bits of the flag word are taken. >* Verify that no other unknown flags are passed along. >*/ > - if (kargs->flags & ~CLONE_LEGACY_FLAGS) >

vger mail woes? (was: Re: [RFC][PATCH] sysctl: Remove the sysctl system call)

* Christian Brauner: > On Thu, Oct 03, 2019 at 08:56:19AM +0200, Florian Weimer wrote: >> Is anyone else getting a very incomplete set of messages in this >> thread? >> >> These changes likely matter to glibc, and I've yet to see the actual >> patch. Woul

Re: [RFC][PATCH] sysctl: Remove the sysctl system call

Is anyone else getting a very incomplete set of messages in this thread? These changes likely matter to glibc, and I've yet to see the actual patch. Would someone please forward it to me? The original message didn't make it into the lore.kernel.org archives (the cross-post to linux-kernel

Re: For review: pidfd_send_signal(2) manual page

* Michael Kerrisk: >If these conditions don't hold true, then the child process should >instead be created using clone(2) with the CLONE_PID flag. I think this should be CLONE_PIDFD.

Re: For review: pidfd_open(2) manual page

* Michael Kerrisk: >>>static >>>int pidfd_open(pid_t pid, unsigned int flags) >>>{ >>>return syscall(__NR_pidfd_open, pid, flags); >>>} >> >> Please call this function something else (not pidfd_open), so that the >> example continues to work if glibc

Re: For review: pidfd_send_signal(2) manual page

* Michael Kerrisk: > SYNOPSIS >int pidfd_send_signal(int pidfd, int sig, siginfo_t info, > unsigned int flags); This probably should reference a header for siginfo_t. >ESRCH The target process does not exist. If the descriptor is valid, does this

Re: For review: pidfd_open(2) manual page

* Michael Kerrisk: > SYNOPSIS >int pidfd_open(pid_t pid, unsigned int flags); Should this mention for pid_t? > ERRORS >EINVAL flags is not 0. > >EINVAL pid is not valid. > >ESRCH The process specified by pid does not exist. Presumably, EMFILE and ENFILE are

Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2()

* Linus Torvalds: > Violently agreed. And that's kind of what the GRND_EXPLICIT is really > aiming for. > > However, it's worth noting that nobody should ever use GRND_EXPLICIT > directly. That's just the name for the bit. The actual users would use > GRND_INSECURE or GRND_SECURE. Should we

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

* Mathieu Desnoyers: > I'm unsure whether there are changes I need to do in my rseq patchset, or > if this is a separate issue that will be fixed separately before glibc 2.31 > is out, which would then update the rseq bits accordingly ? Someone else (perhaps me) has to fix __libc_multiple_libcs.

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

* Florian Weimer: > * Carlos O'Donell: > >> On 9/11/19 3:08 PM, Florian Weimer wrote: >>> * Carlos O'Donell: >>> >>>> It would be easier to merge the patch set if it were just an unconditional >>>> registration like we do for set_robust_

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

* Carlos O'Donell: > On 9/11/19 3:08 PM, Florian Weimer wrote: >> * Carlos O'Donell: >> >>> It would be easier to merge the patch set if it were just an unconditional >>> registration like we do for set_robust_list(). >> >> Note that this depends on

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

* Carlos O'Donell: > It would be easier to merge the patch set if it were just an unconditional > registration like we do for set_robust_list(). Note that this depends on the in-tree system call numbers list, which I still need to finish according to Joseph's specifications. (We have something

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

* Mathieu Desnoyers: > +#ifdef SHARED > + if (rtld_active ()) > +{ > + /* Register rseq ABI to the kernel. */ > + (void) rseq_register_current_thread (); > +} > +#else I think this will need *another* check for the inner libc in an audit module. See what we do in malloc.

Re: [PATCH v2 0/5] Add support for O_MAYEXEC

* Steve Grubb: > Now with LD_AUDIT > $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test 2>&1 | > grep passwd > openat(3, "passwd", O_RDONLY) = 4 > > No O_CLOEXEC flag. I think you need to explain in detail why you consider this a problem. With LD_PRELOAD and

Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

* Jeff Layton: > Even better would be to declare the new flag in some openat2-only flag > space, so there's no confusion about it being supported by legacy open > calls. Isn't that desirable anyway because otherwise fcntl with F_GETFL will give really confusing results? > If glibc wants to

Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

* Tycho Andersen: > On Fri, Sep 06, 2019 at 07:20:51PM +0200, Christian Brauner wrote: >> On Sat, Sep 07, 2019 at 03:07:39AM +1000, Aleksa Sarai wrote: >> > On 2019-09-06, Mickaël Salaün wrote: >> > > >> > > On 06/09/2019 17:56, Florian Weimer wrote: &

Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

Let's assume I want to add support for this to the glibc dynamic loader, while still being able to run on older kernels. Is it safe to try the open call first, with O_MAYEXEC, and if that fails with EINVAL, try again without O_MAYEXEC? Or do I risk disabling this security feature if I do that?

Re: ELF NT_GNU_PROPERTY_TYPE_0 Questions

* Dave Martin: > Hi there, > > Can you clarify a couple of points about the SysV ABI Linux > Extensions [1] for me? > > 1) Can there be more than one NT_GNU_PROPERTY_TYPE_0 note in a valid > ELF file? I think the answer should be "no". Yes, if it has been produced by a link editors which does

Re: New kernel interface for sys_tz and timewarp?

* Paul Eggert: > Linus Torvalds wrote: >> I assume/think that glibc uses (a) environment >> variables and (b) a filesystem-set default (per-user file with a >> system-wide default? I don't know what people do). > glibc relies on the TZ environment variable, with a system-wide > default specified

Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure

* Artem S. Tashkinov: > There's this bug which has been bugging many people for many years > already and which is reproducible in less than a few minutes under the > latest and greatest kernel, 5.2.6. All the kernel parameters are set to > defaults. > > Steps to reproduce: > > 1) Boot with mem=4G

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

* 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()) can be confusing because some of the constants may depend on types that aren't declared by

[PATCH glibc] Linux: Include in under __USE_MISC

is patch depends on the earlier Linux 5.2 compatibility patch which introduced . ]]] 2019-07-22 Florian Weimer * sysdeps/unix/sysv/linux/bits/socket.h [__USE_MISC]: Include . diff --git a/sysdeps/unix/sysv/linux/bits/socket.h b/sysdeps/unix/sysv/linux/bits/socket.h index 082f8b

Re: linux-headers-5.2 and proper use of SIOCGSTAMP

* Arnd Bergmann: > On Sat, Jul 20, 2019 at 8:10 PM Florian Weimer wrote: >> >> * Sergei Trofimovich: >> >> > Should #include always be included by user app? >> > Or should glibc tweak it's definition of '#include ' >> > to make it availa

Re: linux-headers-5.2 and proper use of SIOCGSTAMP

* Sergei Trofimovich: > Should #include always be included by user app? > Or should glibc tweak it's definition of '#include ' > to make it available on both old and new version of linux headers? What is the reason for dropping SIOCGSTAMP from ? If we know that, it will be much easier to

[PATCH] fs: Fix internal type confusion in getdents system calls

should be clearer to prevent the wrap-around. Signed-off-by: Florian Weimer --- fs/readdir.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/readdir.c b/fs/readdir.c index 2f6a4534e0df..d344061e387e 100644 --- a/fs/readdir.c +++ b/fs/readdir.c @@ -159,7 +159,7 @@

Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h

* Linus Torvalds: > On Mon, Jun 17, 2019 at 11:19 AM Florian Weimer wrote: >> > >> > Unlike the "val[]" thing, I don't think anybody is supposed to access >> > those fields directly. >> >> Well, glibc already calls it __val … > > Hmm. If

Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h

* Linus Torvalds: > On Mon, Jun 17, 2019 at 11:03 AM Florian Weimer wrote: >> >> There's also __kernel_fd_set in . I may have >> lumped this up with , but it has the same problem. > > Hmm. > > That one we might be able to just fix by renaming "fds_bits

Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h

* Linus Torvalds: >> A different approach would rename to something more >> basic, exclude the two structs, and move all internal #includes which do >> need the structs to the new header. > > In fact, I wouldn't even rename at all, I'd just make > sure it's namespace-clean. > > I _think_ the

Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h

* Linus Torvalds: > On Fri, Jun 7, 2019 at 11:43 AM Florian Weimer wrote: >> >> On the glibc side, we nowadays deal with this by splitting headers >> further. (We used to suppress definitions with macros, but that tended >> to become convoluted.) In this

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

* Mathieu Desnoyers: > - On Jun 14, 2019, at 3:42 PM, Florian Weimer fwei...@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>> + /* Publicize rseq registration ownership. This must be performed >>> + after rtld re-relocation, before invoking

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

* Mathieu Desnoyers: > + /* Publicize rseq registration ownership. This must be performed > + after rtld re-relocation, before invoking constructors of > + preloaded libraries. */ > + rseq_init (); Please add a comment that IFUNC resolvers do not see the initialized value. I think

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

* Mathieu Desnoyers: > - On Jun 14, 2019, at 3:09 PM, Florian Weimer fwei...@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>> But my original issue remains: if I define a variable called __rseq_handled >>> within either the main executable or t

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

* Mathieu Desnoyers: > But my original issue remains: if I define a variable called __rseq_handled > within either the main executable or the preloaded library, it overshadows > the libc one: > > efficios@compudjdev:~/test/libc-sym$ ./a > __rseq_handled main: 0 0x56135fd5102c > __rseq_abi.cpu_id

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

* Mathieu Desnoyers: > * Makefile: > > LIBCPATH=/home/efficios/glibc-test/lib > KERNEL_HEADERS=/home/efficios/git/linux-percpu-dev/usr/include > CFLAGS=-I${KERNEL_HEADERS} -L${LIBCPATH} -Wl,--rpath=${LIBCPATH} > -Wl,--dynamic-linker=${LIBCPATH}/ld-linux-x86-64.so.2 > > all: > gcc ${CFLAGS}

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

* Mathieu Desnoyers: > - On Jun 12, 2019, at 4:00 PM, Mathieu Desnoyers > mathieu.desnoy...@efficios.com wrote: > >> - On Jun 10, 2019, at 4:43 PM, carlos car...@redhat.com wrote: >> >>> On 6/6/19 7:57 AM, Florian Weimer wrote: >>>> Let me

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

* Mathieu Desnoyers: > - On Jun 12, 2019, at 4:22 PM, Florian Weimer fwei...@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>>> It's the registration from libc.so which needs some care. In >>>> particular, we must not override an existing r

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

* Mathieu Desnoyers: >> It's the registration from libc.so which needs some care. In >> particular, we must not override an existing registration. > > OK, so it could check if __rseq_abi.cpu_id is -1, and only > perform registration if it is the case. Or do you have another > approach in mind ?

Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h

* Linus Torvalds: > If we're changing kernel header files, it's easy enough to change the > kernel users. I'd be more worried about user space that *uses* that > thing, and currently accesses 'val[]' by name. > > So the patch looks a bit odd to me. How are people supposed to use > fsid_t if they

Re: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h

* Joseph Myers: > What happened with this patch (posted 19 March)? I found today that we > can't use Linux 5.1 headers in glibc testing because the namespace issues > are still present in the headers as of the release. This regression fix still hasn't been merged into Linus' tree. What is

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

* Mathieu Desnoyers: > Should we plan ahead for such scheme to override which library "owns" rseq > registration from a LD_PRELOAD library ? If so, then we would want glibc to > set __rseq_handled _after_ LD_PRELOAD ctors are executed. I don't think so. The LD_PRELOAD phase is not clearly

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

* Mathieu Desnoyers: > - On May 31, 2019, at 11:46 AM, Florian Weimer fwei...@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>> Let's break this down into the various sub-issues involved: >>> >>> 1) How early do we need to setup rseq ? Shoul

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

* Mathieu Desnoyers: > Let's break this down into the various sub-issues involved: > > 1) How early do we need to setup rseq ? Should it be setup before: >- LD_PRELOAD .so constructors ? > - Without circular dependency, > - With circular dependency, >- audit libraries

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

* Mathieu Desnoyers: > I found that it's because touching a __thread variable from > ld-linux-x86-64.so.2 ends up setting the DF_STATIC_TLS flag > for that .so, which is really not expected. > > Even if I tweak the assert to make it more lenient there, > touching the __thread variable ends up

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

* Mathieu Desnoyers: > +/* volatile because fields can be read/updated by the kernel. */ > +__thread volatile struct rseq __rseq_abi = { > + .cpu_id = RSEQ_CPU_ID_UNINITIALIZED, > +}; As I've explained repeatedly, the volatile qualifier is wrong because it is impossible to get rid of it.

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: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

* Linus Torvalds: > On Tue, Apr 30, 2019 at 9:19 AM Linus Torvalds > wrote: >> >> Of course, if you *don't* need the exact vfork() semantics, clone >> itself actually very much supports a callback model with s separate >> stack. You can basically do this: >> >> - allocate new stack for the

Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

* Linus Torvalds: > Note that vfork() is "exciting" for the compiler in much the same way > "setjmp/longjmp()" is, because of the shared stack use in the child > and the parent. It is *very* easy to get this wrong and cause massive > and subtle memory corruption issues because the parent returns

Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

* Linus Torvalds: > On Mon, Apr 29, 2019 at 1:38 PM Florian Weimer wrote: >> >> In Linux-as-the-ABI (as opposed to Linux-as-the-implementation), vfork >> is sometimes implemented as fork, so applications cannot rely on the >> vfork behavior regarding the stopped pa

Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

* Jann Horn: >> int clone_temporary(int (*fn)(void *arg), void *arg, pid_t *child_pid, >> ) >> >> and then you'd use it like this to fork off a child process: >> >> int spawn_shell_subprocess_(void *arg) { >> char *cmdline = arg; >> execl("/bin/sh", "sh", "-c", cmdline); >> return -1; >> }

Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

* Linus Torvalds: > On Mon, Apr 29, 2019 at 12:55 PM Jann Horn wrote: >> >> ... I guess that already has a name, and it's called vfork(). (Well, >> except that the Linux vfork() isn't a real vfork().) > > What? > > Linux vfork() is very much a real vfork(). What do you mean? In Linux-as-the-ABI

Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD]

* Andy Lutomirski: > I would personally *love* it if distros started setting no_new_privs > for basically all processes. Wouldn't no_new_privs inhibit all security transitions, including those that reduce privileges? And therefore effectively reduce security? > Anyway, clone(2) is an enormous

Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

* Steve Grubb: > On Tuesday, April 16, 2019 7:49:39 AM EDT Florian Weimer wrote: >> * Steve Grubb: >> > This flag that is being proposed means that you would have to patch all >> > interpreters to use it. If you are sure that upstreams will accept that, >>

Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

* Steve Grubb: > This flag that is being proposed means that you would have to patch all > interpreters to use it. If you are sure that upstreams will accept that, why > not just change the policy to interpreters shouldn't execute anything unless > the execute bit is set? That is simpler and

Re: rseq/arm32: choosing rseq code signature

* Mathieu Desnoyers: > /* > * TODO: document trap instruction objdump output on each sub-architecture > * instruction sets, as well as instruction set extensions. > */ > #define RSEQ_SIG 0x Will RSEQ_SIG actually be needed at run time outside the rseq implementation library (whether

Re: [PATCH] sched/core: expand sched_getaffinity(2) to return number of CPUs

* Alexey Dobriyan: >> >> Patch overloads sched_getaffinity(len=0) to simply return "nr_cpu_ids". >> >> This will make gettting CPU mask require at most 2 system calls >> >> and will eliminate unnecessary code. >> >> >> >> len=0 is chosen so that >> >> * passing zeroes is the simplest thing >> >>

Re: [PATCH] sched/core: expand sched_getaffinity(2) to return number of CPUs

* Peter Zijlstra: > On Fri, Apr 05, 2019 at 12:16:39PM +0200, Florian Weimer wrote: > >> > True; but I suppose glibc already does lots of that anyway, right? It >> > does contain the right information. >> >> If I recall correctly my last investigation, >

Re: [PATCH] sched/core: expand sched_getaffinity(2) to return number of CPUs

* Peter Zijlstra: > On Wed, Apr 03, 2019 at 11:08:09PM +0300, Alexey Dobriyan wrote: >> Currently there is no easy way to get the number of CPUs on the system. The size of the affinity mask is only related to the number of CPUs in the system in such a way that the number of CPUs cannot be larger

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

* Carlos O'Donell: > On 4/2/19 3:08 AM, Florian Weimer wrote: >> * Michael Ellerman: >> >>> I'm a bit vague on what we're trying to do here. >>> >>> But it seems like you want some sort of "eye catcher" prior to the branch? >>> >>

Re: [PATCH v2 0/5] pid: add pidfd_open()

* Daniel Colascione: > But doesn't the CSIGNAL approach still require that libraries somehow > coordinate which non-SIGCHLD signal they use? (Signal coordination a > separate problem, unfortunately.) There's already an allocation mechanism for realtime signals in glibc, via

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

* Michael Ellerman: > I'm a bit vague on what we're trying to do here. > > But it seems like you want some sort of "eye catcher" prior to the branch? > > That value is a valid instruction on current CPUs (rlwimi. > r5,r24,6,1,9), and even if it wasn't it could become one in future. > > If you

Re: [PATCH 2/3] mm/filemap: initiate readahead even if IOCB_NOWAIT is set for the I/O

* Jiri Kosina: > On Wed, 30 Jan 2019, Florian Weimer wrote: > >> > preadv2(RWF_NOWAIT) can be used to open a side-channel to pagecache >> > contents, as it reveals metadata about residency of pages in >> > pagecache. >> > >> > If preadv2(RWF_NOW

Re: [PATCH 2/3] mm/filemap: initiate readahead even if IOCB_NOWAIT is set for the I/O

* Vlastimil Babka: > preadv2(RWF_NOWAIT) can be used to open a side-channel to pagecache > contents, as it reveals metadata about residency of pages in > pagecache. > > If preadv2(RWF_NOWAIT) returns immediately, it provides a clear "page > not resident" information, and vice versa. > > Close

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

* Mathieu Desnoyers: > - On Jan 14, 2019, at 10:55 AM, Florian Weimer fwei...@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>> Therefore, both symbols will end up in >>> sysdeps/unix/sysv/linux/Versions. >> >> I'm not sure what you mean by

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

* Mathieu Desnoyers: > Now that I think about it, it's important to move the rseq registration > done at nptl init (in my current code) to some lower-level csu initialiation, > so applications that happen _not_ to link against libpthread also get > registered rseq for the main thread. Yes. In

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

* Mathieu Desnoyers: > Therefore, both symbols will end up in > sysdeps/unix/sysv/linux/Versions. I'm not sure what you mean by that. The physical location in the directory tree has little effect on which shared object the symbol is placed in; that will need other changes. >> By the way, you

Re: Can we drop upstream Linux x32 support?

* Thomas Schöbel-Theuer: > 2) please _announce_ _now_ that after the _next_ LTS kernel (whichever > you want to declare as such), you will _afterwards_ drop the legacy > 32bit support for 64 kernels (I am deliberately using "management > speak" here). > > => result: the industry should have to

Re: d_off field in struct dirent and 32-on-64 emulation

* Florian Weimer: > * Adhemerval Zanella: > >> On 27/12/2018 16:09, Florian Weimer wrote: >>> * Adhemerval Zanella: >>> >>>> Also for glibc standpoint, although reverting it back to use getdents >>>> syscall for non-LFS mode might fix t

Re: d_off field in struct dirent and 32-on-64 emulation

* Adhemerval Zanella: > On 27/12/2018 16:09, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> Also for glibc standpoint, although reverting it back to use getdents >>> syscall for non-LFS mode might fix this issue for architectures that >>>

Re: d_off field in struct dirent and 32-on-64 emulation

* Dmitry V. Levin: > On Thu, Dec 27, 2018 at 06:18:19PM +0100, Florian Weimer wrote: >> We have a bit of an interesting problem with respect to the d_off >> field in struct dirent. >> >> When running a 64-bit kernel on certain file systems, notably ext4, >> this

Re: d_off field in struct dirent and 32-on-64 emulation

* Adhemerval Zanella: > Also for glibc standpoint, although reverting it back to use getdents > syscall for non-LFS mode might fix this issue for architectures that > provides non-LFS getdents syscall it won't be a fix for architectures > that still provides off_t different than off64_t *and*

Re: d_off field in struct dirent and 32-on-64 emulation

* Andy Lutomirski: >> On Dec 27, 2018, at 10:18 AM, Florian Weimer wrote: >> >> We have a bit of an interesting problem with respect to the d_off >> field in struct dirent. >> >> When running a 64-bit kernel on certain file systems, notably ext4, >

Re: [BUG]Uncalibrated TSC is not accurate enough as a time keeper

* Da Shi Cao: > The cpu_khz and tsc_khz are now read directly by the cpuid > instruction, and they are deemed to be very accurate. But this is not > the case in our situation. The OS time lags behind about 8 seconds per > hour. The CPU information is as follows: Is virtualization involved? Do

d_off field in struct dirent and 32-on-64 emulation

We have a bit of an interesting problem with respect to the d_off field in struct dirent. When running a 64-bit kernel on certain file systems, notably ext4, this field uses the full 63 bits even for small directories (strace -v output, wrapped here for readability): getdents(3, [

Re: Can we drop upstream Linux x32 support?

* Rich Felker: > This is all useless (and wrong since tv_nsec is required to have type > long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug > in glibc's x32). We should be able to fix standards if they prove unworkable in practice. In my opinion, if standards require complex

Re: Can we drop upstream Linux x32 support?

* Rich Felker: > On Thu, Dec 13, 2018 at 05:04:59PM +0100, Florian Weimer wrote: >> * Rich Felker: >> >> >> If the compiler can handle the zeroing, that would be great, though not >> >> sure how (some __attribute__((zero)) which generates a type constr

Re: Can we drop upstream Linux x32 support?

* Rich Felker: >> If the compiler can handle the zeroing, that would be great, though not >> sure how (some __attribute__((zero)) which generates a type constructor >> for such structure; it kind of departs from what the C language offers). > > The compiler fundamentally can't. At the very least

Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC

* Mimi Zohar: > The indication needs to be set during file open, before the open > returns to the caller.  This is the point where ima_file_check() > verifies the file's signature.  On failure, access to the file is > denied. Does this verification happen for open with O_PATH? Thanks, Florian

Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC

* Matthew Wilcox: > On Wed, Dec 12, 2018 at 09:17:07AM +0100, Mickaël Salaün wrote: >> The goal of this patch series is to control script interpretation. A >> new O_MAYEXEC flag used by sys_open() is added to enable userland script >> interpreter to delegate to the kernel (and thus the system

Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC

* James Morris: > On Wed, 12 Dec 2018, Florian Weimer wrote: > >> * James Morris: >> >> > If you're depending on the script interpreter to flag that the user may >> > execute code, this seems to be equivalent in security terms to depending >> > on

Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC

* James Morris: > If you're depending on the script interpreter to flag that the user may > execute code, this seems to be equivalent in security terms to depending > on the user. e.g. what if the user uses ptrace and clears O_MAYEXEC? The argument I've heard is this: Using ptrace (and adding

<    1   2   3   4   5   6   7   >