* Re: [PATCH v2 1/4] copy_sighand: Handle architectures where sizeof(unsigned long) < sizeof(u64)
From: Arnd Bergmann @ 2025-09-01 13:19 UTC (permalink / raw)
To: schuster.simon@siemens-energy.com, Dinh Nguyen, Christian Brauner,
Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Benjamin Segall, Mel Gorman, Valentin Schneider, Kees Cook,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, guoren,
Oleg Nesterov, Jens Axboe, Alexander Viro, Jan Kara, Tejun Heo,
Johannes Weiner, Michal Koutný, Paul Moore, Serge Hallyn,
James Morris, Serge E. Hallyn, Anna-Maria Gleixner,
Frederic Weisbecker, Thomas Gleixner, Masami Hiramatsu,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Mathieu Desnoyers, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, John Johansen, Stephen Smalley,
Ondrej Mosnacek, Kentaro Takeda, Tetsuo Handa, Richard Henderson,
Matt Turner, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Brian Cain, Huacai Chen, WANG Xuerui,
Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer, Jonas Bonn,
Stefan Kristiansson, Stafford Horne, James E . J . Bottomley,
Helge Deller, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andreas Larsson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Chris Zankel,
Max Filippov
Cc: linux-mm, linux-kernel, linux-riscv, linux-csky@vger.kernel.org,
linux-block, linux-fsdevel, cgroups, linux-security-module,
linux-trace-kernel, Netdev, linux-perf-users, apparmor, selinux,
linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
loongarch, linux-m68k, linux-mips, linux-openrisc@vger.kernel.org,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-um, stable
In-Reply-To: <20250901-nios2-implement-clone3-v2-1-53fcf5577d57@siemens-energy.com>
On Mon, Sep 1, 2025, at 15:09, Simon Schuster via B4 Relay wrote:
> This commit fixes the bug by always passing clone_flags to copy_sighand
> via their declared u64 type, invariant of architecture-dependent integer
> sizes.
>
> Fixes: b612e5df4587 ("clone3: add CLONE_CLEAR_SIGHAND")
> Cc: stable@vger.kernel.org # linux-5.5+
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v2 1/4] copy_sighand: Handle architectures where sizeof(unsigned long) < sizeof(u64)
From: David Hildenbrand @ 2025-09-01 13:24 UTC (permalink / raw)
To: schuster.simon, Dinh Nguyen, Christian Brauner, Arnd Bergmann,
Andrew Morton, Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport
Cc: linux-mm, linux-kernel, linux-riscv, linux-csky, linux-block,
linux-fsdevel, cgroups, linux-security-module, linux-trace-kernel,
netdev, linux-perf-users, apparmor, selinux, linux-alpha,
linux-snps-arc, linux-arm-kernel, linux-hexagon, loongarch,
linux-m68k, linux-mips, linux-openrisc, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, linux-um, stable
In-Reply-To: <20250901-nios2-implement-clone3-v2-1-53fcf5577d57@siemens-energy.com>
On 01.09.25 15:09, Simon Schuster via B4 Relay wrote:
> From: Simon Schuster <schuster.simon@siemens-energy.com>
>
> With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
> clone3") the effective bit width of clone_flags on all architectures was
> increased from 32-bit to 64-bit. However, the signature of the copy_*
> helper functions (e.g., copy_sighand) used by copy_process was not
> adapted.
>
> As such, they truncate the flags on any 32-bit architectures that
> supports clone3 (arc, arm, csky, m68k, microblaze, mips32, openrisc,
> parisc32, powerpc32, riscv32, x86-32 and xtensa).
>
> For copy_sighand with CLONE_CLEAR_SIGHAND being an actual u64
> constant, this triggers an observable bug in kernel selftest
> clone3_clear_sighand:
>
> if (clone_flags & CLONE_CLEAR_SIGHAND)
>
> in function copy_sighand within fork.c will always fail given:
>
> unsigned long /* == uint32_t */ clone_flags
> #define CLONE_CLEAR_SIGHAND 0x100000000ULL
>
> This commit fixes the bug by always passing clone_flags to copy_sighand
> via their declared u64 type, invariant of architecture-dependent integer
> sizes.
>
> Fixes: b612e5df4587 ("clone3: add CLONE_CLEAR_SIGHAND")
> Cc: stable@vger.kernel.org # linux-5.5+
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
(stripping To list)
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 3/4] arch: copy_thread: pass clone_flags as u64
From: Arnd Bergmann @ 2025-09-01 13:30 UTC (permalink / raw)
To: schuster.simon@siemens-energy.com, Dinh Nguyen, Christian Brauner,
Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Benjamin Segall, Mel Gorman, Valentin Schneider, Kees Cook,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, guoren,
Oleg Nesterov, Jens Axboe, Alexander Viro, Jan Kara, Tejun Heo,
Johannes Weiner, Michal Koutný, Paul Moore, Serge Hallyn,
James Morris, Serge E. Hallyn, Anna-Maria Gleixner,
Frederic Weisbecker, Thomas Gleixner, Masami Hiramatsu,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Mathieu Desnoyers, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, John Johansen, Stephen Smalley,
Ondrej Mosnacek, Kentaro Takeda, Tetsuo Handa, Richard Henderson,
Matt Turner, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Brian Cain, Huacai Chen, WANG Xuerui,
Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer, Jonas Bonn,
Stefan Kristiansson, Stafford Horne, James E . J . Bottomley,
Helge Deller, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andreas Larsson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Chris Zankel,
Max Filippov
Cc: linux-mm, linux-kernel, linux-riscv, linux-csky@vger.kernel.org,
linux-block, linux-fsdevel, cgroups, linux-security-module,
linux-trace-kernel, Netdev, linux-perf-users, apparmor, selinux,
linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
loongarch, linux-m68k, linux-mips, linux-openrisc@vger.kernel.org,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-um
In-Reply-To: <20250901-nios2-implement-clone3-v2-3-53fcf5577d57@siemens-energy.com>
On Mon, Sep 1, 2025, at 15:09, Simon Schuster via B4 Relay wrote:
> From: Simon Schuster <schuster.simon@siemens-energy.com>
>
> With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
> clone3") the effective bit width of clone_flags on all architectures was
> increased from 32-bit to 64-bit, with a new type of u64 for the flags.
> However, for most consumers of clone_flags the interface was not
> changed from the previous type of unsigned long.
>
> While this works fine as long as none of the new 64-bit flag bits
> (CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still
> undesirable in terms of the principle of least surprise.
>
> Thus, this commit fixes all relevant interfaces of the copy_thread
> function that is called from copy_process to consistently pass
> clone_flags as u64, so that no truncation to 32-bit integers occurs on
> 32-bit architectures.
>
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v2 2/4] copy_process: pass clone_flags as u64 across calltree
From: Arnd Bergmann @ 2025-09-01 13:35 UTC (permalink / raw)
To: schuster.simon@siemens-energy.com, Dinh Nguyen, Christian Brauner,
Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Benjamin Segall, Mel Gorman, Valentin Schneider, Kees Cook,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, guoren,
Oleg Nesterov, Jens Axboe, Alexander Viro, Jan Kara, Tejun Heo,
Johannes Weiner, Michal Koutný, Paul Moore, Serge Hallyn,
James Morris, Serge E. Hallyn, Anna-Maria Gleixner,
Frederic Weisbecker, Thomas Gleixner, Masami Hiramatsu,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Mathieu Desnoyers, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, John Johansen, Stephen Smalley,
Ondrej Mosnacek, Kentaro Takeda, Tetsuo Handa, Richard Henderson,
Matt Turner, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Brian Cain, Huacai Chen, WANG Xuerui,
Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer, Jonas Bonn,
Stefan Kristiansson, Stafford Horne, James E . J . Bottomley,
Helge Deller, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andreas Larsson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Chris Zankel,
Max Filippov
Cc: linux-mm, linux-kernel, linux-riscv, linux-csky@vger.kernel.org,
linux-block, linux-fsdevel, cgroups, linux-security-module,
linux-trace-kernel, Netdev, linux-perf-users, apparmor, selinux,
linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
loongarch, linux-m68k, linux-mips, linux-openrisc@vger.kernel.org,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-um
In-Reply-To: <20250901-nios2-implement-clone3-v2-2-53fcf5577d57@siemens-energy.com>
On Mon, Sep 1, 2025, at 15:09, Simon Schuster via B4 Relay wrote:
> From: Simon Schuster <schuster.simon@siemens-energy.com>
>
> With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
> clone3") the effective bit width of clone_flags on all architectures was
> increased from 32-bit to 64-bit, with a new type of u64 for the flags.
> However, for most consumers of clone_flags the interface was not
> changed from the previous type of unsigned long.
>
> While this works fine as long as none of the new 64-bit flag bits
> (CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still
> undesirable in terms of the principle of least surprise.
>
> Thus, this commit fixes all relevant interfaces of callees to
> sys_clone3/copy_process (excluding the architecture-specific
> copy_thread) to consistently pass clone_flags as u64, so that
> no truncation to 32-bit integers occurs on 32-bit architectures.
>
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v2 4/4] nios2: implement architecture-specific portion of sys_clone3
From: Arnd Bergmann @ 2025-09-01 13:35 UTC (permalink / raw)
To: schuster.simon@siemens-energy.com, Dinh Nguyen, Christian Brauner,
Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Benjamin Segall, Mel Gorman, Valentin Schneider, Kees Cook,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti, guoren,
Oleg Nesterov, Jens Axboe, Alexander Viro, Jan Kara, Tejun Heo,
Johannes Weiner, Michal Koutný, Paul Moore, Serge Hallyn,
James Morris, Serge E. Hallyn, Anna-Maria Gleixner,
Frederic Weisbecker, Thomas Gleixner, Masami Hiramatsu,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Mathieu Desnoyers, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, John Johansen, Stephen Smalley,
Ondrej Mosnacek, Kentaro Takeda, Tetsuo Handa, Richard Henderson,
Matt Turner, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Brian Cain, Huacai Chen, WANG Xuerui,
Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer, Jonas Bonn,
Stefan Kristiansson, Stafford Horne, James E . J . Bottomley,
Helge Deller, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andreas Larsson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Chris Zankel,
Max Filippov
Cc: linux-mm, linux-kernel, linux-riscv, linux-csky@vger.kernel.org,
linux-block, linux-fsdevel, cgroups, linux-security-module,
linux-trace-kernel, Netdev, linux-perf-users, apparmor, selinux,
linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
loongarch, linux-m68k, linux-mips, linux-openrisc@vger.kernel.org,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-um
In-Reply-To: <20250901-nios2-implement-clone3-v2-4-53fcf5577d57@siemens-energy.com>
On Mon, Sep 1, 2025, at 15:09, Simon Schuster via B4 Relay wrote:
> From: Simon Schuster <schuster.simon@siemens-energy.com>
>
> This commit adds the sys_clone3 entry point for nios2. An
> architecture-specific wrapper (__sys_clone3) is required to save and
> restore additional registers to the kernel stack via SAVE_SWITCH_STACK
> and RESTORE_SWITCH_STACK.
>
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v2 2/4] copy_process: pass clone_flags as u64 across calltree
From: David Hildenbrand @ 2025-09-01 13:38 UTC (permalink / raw)
To: schuster.simon, Dinh Nguyen, Christian Brauner, Arnd Bergmann,
Andrew Morton, Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport
Cc: linux-mm, linux-kernel, linux-riscv, linux-csky, linux-block,
linux-fsdevel, cgroups, linux-security-module, linux-trace-kernel,
netdev, linux-perf-users, apparmor, selinux, linux-alpha,
linux-snps-arc, linux-arm-kernel, linux-hexagon, loongarch,
linux-m68k, linux-mips, linux-openrisc, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, linux-um
In-Reply-To: <20250901-nios2-implement-clone3-v2-2-53fcf5577d57@siemens-energy.com>
On 01.09.25 15:09, Simon Schuster via B4 Relay wrote:
> From: Simon Schuster <schuster.simon@siemens-energy.com>
>
> With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
> clone3") the effective bit width of clone_flags on all architectures was
> increased from 32-bit to 64-bit, with a new type of u64 for the flags.
> However, for most consumers of clone_flags the interface was not
> changed from the previous type of unsigned long.
>
> While this works fine as long as none of the new 64-bit flag bits
> (CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still
> undesirable in terms of the principle of least surprise.
>
> Thus, this commit fixes all relevant interfaces of callees to
> sys_clone3/copy_process (excluding the architecture-specific
> copy_thread) to consistently pass clone_flags as u64, so that
> no truncation to 32-bit integers occurs on 32-bit architectures.
>
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
> block/blk-ioc.c | 2 +-
> fs/namespace.c | 2 +-
> include/linux/cgroup.h | 4 ++--
> include/linux/cred.h | 2 +-
> include/linux/iocontext.h | 6 +++---
> include/linux/ipc_namespace.h | 4 ++--
> include/linux/lsm_hook_defs.h | 2 +-
> include/linux/mnt_namespace.h | 2 +-
> include/linux/nsproxy.h | 2 +-
> include/linux/pid_namespace.h | 4 ++--
> include/linux/rseq.h | 4 ++--
> include/linux/sched/task.h | 2 +-
> include/linux/security.h | 4 ++--
> include/linux/sem.h | 4 ++--
> include/linux/time_namespace.h | 4 ++--
> include/linux/uprobes.h | 4 ++--
> include/linux/user_events.h | 4 ++--
> include/linux/utsname.h | 4 ++--
> include/net/net_namespace.h | 4 ++--
> include/trace/events/task.h | 6 +++---
> ipc/namespace.c | 2 +-
> ipc/sem.c | 2 +-
> kernel/cgroup/namespace.c | 2 +-
> kernel/cred.c | 2 +-
> kernel/events/uprobes.c | 2 +-
> kernel/fork.c | 8 ++++----
> kernel/nsproxy.c | 4 ++--
> kernel/pid_namespace.c | 2 +-
> kernel/sched/core.c | 4 ++--
> kernel/sched/fair.c | 2 +-
> kernel/sched/sched.h | 4 ++--
> kernel/time/namespace.c | 2 +-
> kernel/utsname.c | 2 +-
> net/core/net_namespace.c | 2 +-
> security/apparmor/lsm.c | 2 +-
> security/security.c | 2 +-
> security/selinux/hooks.c | 2 +-
> security/tomoyo/tomoyo.c | 2 +-
> 38 files changed, 59 insertions(+), 59 deletions(-)
>
> diff --git a/block/blk-ioc.c b/block/blk-ioc.c
> index 9fda3906e5f5..d15918d7fabb 100644
> --- a/block/blk-ioc.c
(adjust To: list)
Hopefully we caught most of them. The ones not called "clone_flags" are
a bit nasty.
We could have split of some changes (e.g., trace event), but likely not
worth it.
Thanks!
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 3/4] arch: copy_thread: pass clone_flags as u64
From: Russell King (Oracle) @ 2025-09-01 13:39 UTC (permalink / raw)
To: schuster.simon
Cc: Dinh Nguyen, Christian Brauner, Arnd Bergmann, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, Kees Cook, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Guo Ren, Oleg Nesterov, Jens Axboe,
Alexander Viro, Jan Kara, Tejun Heo, Johannes Weiner,
Michal Koutný, Paul Moore, Serge Hallyn, James Morris,
Serge E. Hallyn, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Masami Hiramatsu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Mathieu Desnoyers,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
John Johansen, Stephen Smalley, Ondrej Mosnacek, Kentaro Takeda,
Tetsuo Handa, Richard Henderson, Matt Turner, Vineet Gupta,
Catalin Marinas, Will Deacon, Brian Cain, Huacai Chen,
WANG Xuerui, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andreas Larsson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Chris Zankel,
Max Filippov, linux-mm, linux-kernel, linux-riscv, linux-csky,
linux-block, linux-fsdevel, cgroups, linux-security-module,
linux-trace-kernel, netdev, linux-perf-users, apparmor, selinux,
linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
loongarch, linux-m68k, linux-mips, linux-openrisc, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, linux-um
In-Reply-To: <20250901-nios2-implement-clone3-v2-3-53fcf5577d57@siemens-energy.com>
On Mon, Sep 01, 2025 at 03:09:52PM +0200, Simon Schuster via B4 Relay wrote:
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index e16ed102960c..d7aa95225c70 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -234,7 +234,7 @@ asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");
>
> int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
> {
> - unsigned long clone_flags = args->flags;
> + u64 clone_flags = args->flags;
> unsigned long stack_start = args->stack;
> unsigned long tls = args->tls;
> struct thread_info *thread = task_thread_info(p);
We only have one user of clone_flags in this function, which is:
if (clone_flags & CLONE_SETTLS)
I would much rather clone_flags was removed, and this changed to:
if (args->flags & CLONE_SETTLS)
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 3/4] arch: copy_thread: pass clone_flags as u64
From: David Hildenbrand @ 2025-09-01 13:39 UTC (permalink / raw)
To: schuster.simon, Dinh Nguyen, Christian Brauner, Arnd Bergmann,
Andrew Morton, Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport
Cc: linux-mm, linux-kernel, linux-riscv, linux-csky, linux-block,
linux-fsdevel, cgroups, linux-security-module, linux-trace-kernel,
netdev, linux-perf-users, apparmor, selinux, linux-alpha,
linux-snps-arc, linux-arm-kernel, linux-hexagon, loongarch,
linux-m68k, linux-mips, linux-openrisc, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, linux-um
In-Reply-To: <20250901-nios2-implement-clone3-v2-3-53fcf5577d57@siemens-energy.com>
On 01.09.25 15:09, Simon Schuster via B4 Relay wrote:
> From: Simon Schuster <schuster.simon@siemens-energy.com>
>
> With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
> clone3") the effective bit width of clone_flags on all architectures was
> increased from 32-bit to 64-bit, with a new type of u64 for the flags.
> However, for most consumers of clone_flags the interface was not
> changed from the previous type of unsigned long.
>
> While this works fine as long as none of the new 64-bit flag bits
> (CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still
> undesirable in terms of the principle of least surprise.
>
> Thus, this commit fixes all relevant interfaces of the copy_thread
> function that is called from copy_process to consistently pass
> clone_flags as u64, so that no truncation to 32-bit integers occurs on
> 32-bit architectures.
>
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
> ---
> arch/alpha/kernel/process.c | 2 +-
> arch/arc/kernel/process.c | 2 +-
> arch/arm/kernel/process.c | 2 +-
> arch/arm64/kernel/process.c | 2 +-
> arch/csky/kernel/process.c | 2 +-
> arch/hexagon/kernel/process.c | 2 +-
> arch/loongarch/kernel/process.c | 2 +-
> arch/m68k/kernel/process.c | 2 +-
> arch/microblaze/kernel/process.c | 2 +-
> arch/mips/kernel/process.c | 2 +-
> arch/nios2/kernel/process.c | 2 +-
> arch/openrisc/kernel/process.c | 2 +-
> arch/parisc/kernel/process.c | 2 +-
> arch/powerpc/kernel/process.c | 2 +-
> arch/riscv/kernel/process.c | 2 +-
> arch/s390/kernel/process.c | 2 +-
> arch/sh/kernel/process_32.c | 2 +-
> arch/sparc/kernel/process_32.c | 2 +-
> arch/sparc/kernel/process_64.c | 2 +-
> arch/um/kernel/process.c | 2 +-
> arch/x86/include/asm/fpu/sched.h | 2 +-
> arch/x86/include/asm/shstk.h | 4 ++--
> arch/x86/kernel/fpu/core.c | 2 +-
> arch/x86/kernel/process.c | 2 +-
> arch/x86/kernel/shstk.c | 2 +-
> arch/xtensa/kernel/process.c | 2 +-
> 26 files changed, 27 insertions(+), 27 deletions(-)
>
(Adjust To: list)
Thanks!
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 0/4] nios2: Add architecture support for clone3
From: Christian Brauner @ 2025-09-01 13:40 UTC (permalink / raw)
To: schuster.simon
Cc: Dinh Nguyen, Arnd Bergmann, Andrew Morton, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Valentin Schneider, Kees Cook,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Guo Ren, Oleg Nesterov, Jens Axboe, Alexander Viro, Jan Kara,
Tejun Heo, Johannes Weiner, Michal Koutný, Paul Moore,
Serge Hallyn, James Morris, Serge E. Hallyn, Anna-Maria Behnsen,
Frederic Weisbecker, Thomas Gleixner, Masami Hiramatsu,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Mathieu Desnoyers, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, John Johansen, Stephen Smalley,
Ondrej Mosnacek, Kentaro Takeda, Tetsuo Handa, Richard Henderson,
Matt Turner, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Brian Cain, Huacai Chen, WANG Xuerui,
Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer, Jonas Bonn,
Stefan Kristiansson, Stafford Horne, James E.J. Bottomley,
Helge Deller, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andreas Larsson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Chris Zankel,
Max Filippov, linux-mm, linux-kernel, linux-riscv, linux-csky,
linux-block, linux-fsdevel, cgroups, linux-security-module,
linux-trace-kernel, netdev, linux-perf-users, apparmor, selinux,
linux-alpha, linux-snps-arc, linux-arm-kernel, linux-hexagon,
loongarch, linux-m68k, linux-mips, linux-openrisc, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, sparclinux, linux-um, stable
In-Reply-To: <20250901-nios2-implement-clone3-v2-0-53fcf5577d57@siemens-energy.com>
On Mon, Sep 01, 2025 at 03:09:49PM +0200, Simon Schuster via B4 Relay wrote:
> This series adds support for the clone3 system call to the nios2
> architecture. This addresses the build-time warning "warning: clone3()
I did not expect that to happen or matter but fine.
> entry point is missing, please fix" introduced in 505d66d1abfb9
> ("clone3: drop __ARCH_WANT_SYS_CLONE3 macro"). The implementation passes
> the relevant clone3 tests of kselftest when applied on top of
> next-20250815:
>
> ./run_kselftest.sh
> TAP version 13
> 1..4
> # selftests: clone3: clone3
> ok 1 selftests: clone3: clone3
> # selftests: clone3: clone3_clear_sighand
> ok 2 selftests: clone3: clone3_clear_sighand
> # selftests: clone3: clone3_set_tid
> ok 3 selftests: clone3: clone3_set_tid
> # selftests: clone3: clone3_cap_checkpoint_restore
> ok 4 selftests: clone3: clone3_cap_checkpoint_restore
>
> The series also includes a small patch to kernel/fork.c that ensures
> that clone_flags are passed correctly on architectures where unsigned
> long is insufficient to store the u64 clone_flags. It is marked as a fix
> for stable backporting.
>
> As requested, in v2, this series now further tries to correct this type
> error throughout the whole code base. Thus, it now touches a larger
> number of subsystems and all architectures.
I've reworked copy_thread()/copy_thread_tls() a few years ago but I
don't remember why I didn't switch to a u64 for them. Probably because
only CLONE_VM and CLONE_SETTLS mattered. Thanks for doing that.
> Therefore, another test was performed for ARCH=x86_64 (as a
> representative for 64-bit architectures). Here, the series builds cleanly
> without warnings on defconfig with CONFIG_SECURITY_APPARMOR=y and
> CONFIG_SECURITY_TOMOYO=y (to compile-check the LSM-related changes).
> The build further successfully passes testing/selftests/clone3 (with the
> patch from 20241105062948.1037011-1-zhouyuhang1010@163.com to prepare
> clone3_cap_checkpoint_restore for compatibility with the newer libcap
> version on my system).
>
> Is there any option to further preflight check this patch series via
> lkp/KernelCI/etc. for a broader test across architectures, or is this
> degree of testing sufficient to eventually get the series merged?
>
> N.B.: The series is not checkpatch clean right now:
> - include/linux/cred.h, include/linux/mnt_namespace.h:
> function definition arguments without identifier name
> - include/trace/events/task.h:
> space prohibited after that open parenthesis
>
> I did not fix these warnings to keep my changes minimal and reviewable,
> as the issues persist throughout the files and they were not introduced
> by me; I only followed the existing code style and just replaced the
> types. If desired, I'd be happy to make the changes in a potential v3,
> though.
>
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
> ---
> Changes in v2:
> - Introduce "Fixes:" and "Cc: stable@vger.kernel.org" where necessary
> - Factor out "Fixes:" when adapting the datatype of clone_flags for
> easier backports
> - Fix additional instances where `unsigned long` clone_flags is used
> - Reword commit message to make it clearer that any 32-bit arch is
> affected by this bug
> - Link to v1: https://lore.kernel.org/r/20250821-nios2-implement-clone3-v1-0-1bb24017376a@siemens-energy.com
>
> ---
> Simon Schuster (4):
> copy_sighand: Handle architectures where sizeof(unsigned long) < sizeof(u64)
> copy_process: pass clone_flags as u64 across calltree
> arch: copy_thread: pass clone_flags as u64
> nios2: implement architecture-specific portion of sys_clone3
>
> arch/alpha/kernel/process.c | 2 +-
> arch/arc/kernel/process.c | 2 +-
> arch/arm/kernel/process.c | 2 +-
> arch/arm64/kernel/process.c | 2 +-
> arch/csky/kernel/process.c | 2 +-
> arch/hexagon/kernel/process.c | 2 +-
> arch/loongarch/kernel/process.c | 2 +-
> arch/m68k/kernel/process.c | 2 +-
> arch/microblaze/kernel/process.c | 2 +-
> arch/mips/kernel/process.c | 2 +-
> arch/nios2/include/asm/syscalls.h | 1 +
> arch/nios2/include/asm/unistd.h | 2 --
> arch/nios2/kernel/entry.S | 6 ++++++
> arch/nios2/kernel/process.c | 2 +-
> arch/nios2/kernel/syscall_table.c | 1 +
> arch/openrisc/kernel/process.c | 2 +-
> arch/parisc/kernel/process.c | 2 +-
> arch/powerpc/kernel/process.c | 2 +-
> arch/riscv/kernel/process.c | 2 +-
> arch/s390/kernel/process.c | 2 +-
> arch/sh/kernel/process_32.c | 2 +-
> arch/sparc/kernel/process_32.c | 2 +-
> arch/sparc/kernel/process_64.c | 2 +-
> arch/um/kernel/process.c | 2 +-
> arch/x86/include/asm/fpu/sched.h | 2 +-
> arch/x86/include/asm/shstk.h | 4 ++--
> arch/x86/kernel/fpu/core.c | 2 +-
> arch/x86/kernel/process.c | 2 +-
> arch/x86/kernel/shstk.c | 2 +-
> arch/xtensa/kernel/process.c | 2 +-
> block/blk-ioc.c | 2 +-
> fs/namespace.c | 2 +-
> include/linux/cgroup.h | 4 ++--
> include/linux/cred.h | 2 +-
> include/linux/iocontext.h | 6 +++---
> include/linux/ipc_namespace.h | 4 ++--
> include/linux/lsm_hook_defs.h | 2 +-
> include/linux/mnt_namespace.h | 2 +-
> include/linux/nsproxy.h | 2 +-
> include/linux/pid_namespace.h | 4 ++--
> include/linux/rseq.h | 4 ++--
> include/linux/sched/task.h | 2 +-
> include/linux/security.h | 4 ++--
> include/linux/sem.h | 4 ++--
> include/linux/time_namespace.h | 4 ++--
> include/linux/uprobes.h | 4 ++--
> include/linux/user_events.h | 4 ++--
> include/linux/utsname.h | 4 ++--
> include/net/net_namespace.h | 4 ++--
> include/trace/events/task.h | 6 +++---
> ipc/namespace.c | 2 +-
> ipc/sem.c | 2 +-
> kernel/cgroup/namespace.c | 2 +-
> kernel/cred.c | 2 +-
> kernel/events/uprobes.c | 2 +-
> kernel/fork.c | 10 +++++-----
> kernel/nsproxy.c | 4 ++--
> kernel/pid_namespace.c | 2 +-
> kernel/sched/core.c | 4 ++--
> kernel/sched/fair.c | 2 +-
> kernel/sched/sched.h | 4 ++--
> kernel/time/namespace.c | 2 +-
> kernel/utsname.c | 2 +-
> net/core/net_namespace.c | 2 +-
> security/apparmor/lsm.c | 2 +-
> security/security.c | 2 +-
> security/selinux/hooks.c | 2 +-
> security/tomoyo/tomoyo.c | 2 +-
> 68 files changed, 95 insertions(+), 89 deletions(-)
> ---
> base-commit: 1357b2649c026b51353c84ddd32bc963e8999603
> change-id: 20250818-nios2-implement-clone3-7f252c20860b
>
> Best regards,
> --
> Simon Schuster <schuster.simon@siemens-energy.com>
>
>
^ permalink raw reply
* Re: [PATCH v2 0/4] nios2: Add architecture support for clone3
From: Christian Brauner @ 2025-09-01 13:41 UTC (permalink / raw)
To: Simon Schuster
Cc: Christian Brauner, linux-mm, linux-kernel, linux-riscv,
linux-csky, linux-block, linux-fsdevel, cgroups,
linux-security-module, linux-trace-kernel, netdev,
linux-perf-users, apparmor, selinux, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-hexagon, loongarch, linux-m68k,
linux-mips, linux-openrisc, linux-parisc, linuxppc-dev,
linux-s390, linux-sh, sparclinux, linux-um, stable, Dinh Nguyen,
Arnd Bergmann, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Valentin Schneider, Kees Cook,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Guo Ren, Oleg Nesterov, Jens Axboe, Alexander Viro, Jan Kara,
Tejun Heo, Johannes Weiner, Michal Koutný, Paul Moore,
Serge Hallyn, James Morris, Serge E. Hallyn, Anna-Maria Behnsen,
Frederic Weisbecker, Thomas Gleixner, Masami Hiramatsu,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Mathieu Desnoyers, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, John Johansen, Stephen Smalley,
Ondrej Mosnacek, Kentaro Takeda, Tetsuo Handa, Richard Henderson,
Matt Turner, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Brian Cain, Huacai Chen, WANG Xuerui,
Geert Uytterhoeven, Michal Simek, Thomas Bogendoerfer, Jonas Bonn,
Stefan Kristiansson, Stafford Horne, James E.J. Bottomley,
Helge Deller, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andreas Larsson, Richard Weinberger, Anton Ivanov, Johannes Berg,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Chris Zankel,
Max Filippov
In-Reply-To: <20250901-nios2-implement-clone3-v2-0-53fcf5577d57@siemens-energy.com>
On Mon, 01 Sep 2025 15:09:49 +0200, Simon Schuster wrote:
> This series adds support for the clone3 system call to the nios2
> architecture. This addresses the build-time warning "warning: clone3()
> entry point is missing, please fix" introduced in 505d66d1abfb9
> ("clone3: drop __ARCH_WANT_SYS_CLONE3 macro"). The implementation passes
> the relevant clone3 tests of kselftest when applied on top of
> next-20250815:
>
> [...]
Seems fine to me. Thanks for fixing this.
---
Applied to the kernel-6.18.clone3 branch of the vfs/vfs.git tree.
Patches in the kernel-6.18.clone3 branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: kernel-6.18.clone3
[1/4] copy_sighand: Handle architectures where sizeof(unsigned long) < sizeof(u64)
https://git.kernel.org/vfs/vfs/c/04ff48239f46
[2/4] copy_process: pass clone_flags as u64 across calltree
https://git.kernel.org/vfs/vfs/c/5b38576cb8d3
[3/4] arch: copy_thread: pass clone_flags as u64
https://git.kernel.org/vfs/vfs/c/04e760acd97f
[4/4] nios2: implement architecture-specific portion of sys_clone3
https://git.kernel.org/vfs/vfs/c/d7109d2a2358
^ permalink raw reply
* Re: [PATCH v2 3/4] arch: copy_thread: pass clone_flags as u64
From: Geert Uytterhoeven @ 2025-09-01 13:51 UTC (permalink / raw)
To: schuster.simon
Cc: Dinh Nguyen, Christian Brauner, Arnd Bergmann, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, Kees Cook, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Guo Ren, Oleg Nesterov, Jens Axboe,
Alexander Viro, Jan Kara, Tejun Heo, Johannes Weiner,
Michal Koutný, Paul Moore, Serge Hallyn, James Morris,
Serge E. Hallyn, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Masami Hiramatsu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Mathieu Desnoyers,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
John Johansen, Stephen Smalley, Ondrej Mosnacek, Kentaro Takeda,
Tetsuo Handa, Richard Henderson, Matt Turner, Vineet Gupta,
Russell King, Catalin Marinas, Will Deacon, Brian Cain,
Huacai Chen, WANG Xuerui, Michal Simek, Thomas Bogendoerfer,
Jonas Bonn, Stefan Kristiansson, Stafford Horne,
James E.J. Bottomley, Helge Deller, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, Andreas Larsson, Richard Weinberger,
Anton Ivanov, Johannes Berg, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Chris Zankel, Max Filippov, linux-mm,
linux-kernel, linux-riscv, linux-csky, linux-block, linux-fsdevel,
cgroups, linux-security-module, linux-trace-kernel, netdev,
linux-perf-users, apparmor, selinux, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-hexagon, loongarch, linux-m68k,
linux-mips, linux-openrisc, linux-parisc, linuxppc-dev,
linux-s390, linux-sh, sparclinux, linux-um
In-Reply-To: <20250901-nios2-implement-clone3-v2-3-53fcf5577d57@siemens-energy.com>
On Mon, 1 Sept 2025 at 15:10, Simon Schuster via B4 Relay
<devnull+schuster.simon.siemens-energy.com@kernel.org> wrote:
> From: Simon Schuster <schuster.simon@siemens-energy.com>
>
> With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
> clone3") the effective bit width of clone_flags on all architectures was
> increased from 32-bit to 64-bit, with a new type of u64 for the flags.
> However, for most consumers of clone_flags the interface was not
> changed from the previous type of unsigned long.
>
> While this works fine as long as none of the new 64-bit flag bits
> (CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still
> undesirable in terms of the principle of least surprise.
>
> Thus, this commit fixes all relevant interfaces of the copy_thread
> function that is called from copy_process to consistently pass
> clone_flags as u64, so that no truncation to 32-bit integers occurs on
> 32-bit architectures.
>
> Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
Fixes: c5febea0956fd387 ("fork: Pass struct kernel_clone_args into copy_thread")
> arch/m68k/kernel/process.c | 2 +-
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC PATCH v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK)
From: Andy Lutomirski @ 2025-09-01 16:01 UTC (permalink / raw)
To: Jann Horn
Cc: Serge E. Hallyn, Andy Lutomirski, Aleksa Sarai,
Mickaël Salaün, Christian Brauner, Al Viro, Kees Cook,
Paul Moore, Arnd Bergmann, Christian Heimes, Dmitry Vyukov,
Elliott Hughes, Fan Wu, Florian Weimer, Jeff Xu, Jonathan Corbet,
Jordan R Abrahams, Lakshmi Ramasubramanian, Luca Boccassi,
Matt Bobrowski, Miklos Szeredi, Mimi Zohar, Nicolas Bouchinet,
Robert Waite, Roberto Sassu, Scott Shell, Steve Dower,
Steve Grubb, kernel-hardening, linux-api, linux-fsdevel,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <CAG48ez0p1B9nmG3ZyNRywaSYTtEULSpbxueia912nVpg2Q7WYA@mail.gmail.com>
On Mon, Sep 1, 2025 at 4:06 AM Jann Horn <jannh@google.com> wrote:
>
> On Thu, Aug 28, 2025 at 11:01 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Wed, Aug 27, 2025 at 05:32:02PM -0700, Andy Lutomirski wrote:
> > > On Wed, Aug 27, 2025 at 5:14 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
> > > >
> > > > On 2025-08-26, Mickaël Salaün <mic@digikod.net> wrote:
> > > > > On Tue, Aug 26, 2025 at 11:07:03AM +0200, Christian Brauner wrote:
> > > > > > Nothing has changed in that regard and I'm not interested in stuffing
> > > > > > the VFS APIs full of special-purpose behavior to work around the fact
> > > > > > that this is work that needs to be done in userspace. Change the apps,
> > > > > > stop pushing more and more cruft into the VFS that has no business
> > > > > > there.
> > > > >
> > > > > It would be interesting to know how to patch user space to get the same
> > > > > guarantees... Do you think I would propose a kernel patch otherwise?
> > > >
> > > > You could mmap the script file with MAP_PRIVATE. This is the *actual*
> > > > protection the kernel uses against overwriting binaries (yes, ETXTBSY is
> > > > nice but IIRC there are ways to get around it anyway).
> > >
> > > Wait, really? MAP_PRIVATE prevents writes to the mapping from
> > > affecting the file, but I don't think that writes to the file will
> > > break the MAP_PRIVATE CoW if it's not already broken.
> > >
> > > IPython says:
> > >
> > > In [1]: import mmap, tempfile
> > >
> > > In [2]: f = tempfile.TemporaryFile()
> > >
> > > In [3]: f.write(b'initial contents')
> > > Out[3]: 16
> > >
> > > In [4]: f.flush()
> > >
> > > In [5]: map = mmap.mmap(f.fileno(), f.tell(), flags=mmap.MAP_PRIVATE,
> > > prot=mmap.PROT_READ)
> > >
> > > In [6]: map[:]
> > > Out[6]: b'initial contents'
> > >
> > > In [7]: f.seek(0)
> > > Out[7]: 0
> > >
> > > In [8]: f.write(b'changed')
> > > Out[8]: 7
> > >
> > > In [9]: f.flush()
> > >
> > > In [10]: map[:]
> > > Out[10]: b'changed contents'
> >
> > That was surprising to me, however, if I split the reader
> > and writer into different processes, so
>
> Testing this in python is a terrible idea because it obfuscates the
> actual syscalls from you.
>
> > P1:
> > f = open("/tmp/3", "w")
> > f.write('initial contents')
> > f.flush()
> >
> > P2:
> > import mmap
> > f = open("/tmp/3", "r")
> > map = mmap.mmap(f.fileno(), f.tell(), flags=mmap.MAP_PRIVATE, prot=mmap.PROT_READ)
> >
> > Back to P1:
> > f.seek(0)
> > f.write('changed')
> >
> > Back to P2:
> > map[:]
> >
> > Then P2 gives me:
> >
> > b'initial contents'
>
> Because when you executed `f.write('changed')`, Python internally
> buffered the write. "changed" is never actually written into the file
> in your example. If you add a `f.flush()` in P1 after this, running
> `map[:]` in P2 again will show you the new data.
>
These days, one can type in Python, ask an LLM to translate to C, and
get almost-correct output :) Or one can use os.write(), which is
exactly what I should have done.
--Andy
^ permalink raw reply
* Re: [RFC PATCH v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK)
From: Andy Lutomirski @ 2025-09-01 16:25 UTC (permalink / raw)
To: Roberto Sassu
Cc: Aleksa Sarai, Mickaël Salaün, Christian Brauner,
Al Viro, Kees Cook, Paul Moore, Serge Hallyn, Andy Lutomirski,
Arnd Bergmann, Christian Heimes, Dmitry Vyukov, Elliott Hughes,
Fan Wu, Florian Weimer, Jann Horn, Jeff Xu, Jonathan Corbet,
Jordan R Abrahams, Lakshmi Ramasubramanian, Luca Boccassi,
Matt Bobrowski, Miklos Szeredi, Mimi Zohar, Nicolas Bouchinet,
Robert Waite, Roberto Sassu, Scott Shell, Steve Dower,
Steve Grubb, kernel-hardening, linux-api, linux-fsdevel,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <54e27d05bae55749a975bc7cbe109b237b2b1323.camel@huaweicloud.com>
Can you clarify this a bit for those of us who are not well-versed in
exactly what "measurement" does?
On Mon, Sep 1, 2025 at 2:42 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
> > Now, in cases where you have IMA or something and you only permit signed
> > binaries to execute, you could argue there is a different race here (an
> > attacker creates a malicious script, runs it, and then replaces it with
> > a valid script's contents and metadata after the fact to get
> > AT_EXECVE_CHECK to permit the execution). However, I'm not sure that
>
> Uhm, let's consider measurement, I'm more familiar with.
>
> I think the race you wanted to express was that the attacker replaces
> the good script, verified with AT_EXECVE_CHECK, with the bad script
> after the IMA verification but before the interpreter reads it.
>
> Fortunately, IMA is able to cope with this situation, since this race
> can happen for any file open, where of course a file can be not read-
> locked.
I assume you mean that this has nothing specifically to do with
scripts, as IMA tries to protect ordinary (non-"execute" file access)
as well. Am I right?
>
> If the attacker tries to concurrently open the script for write in this
> race window, IMA will report this event (called violation) in the
> measurement list, and during remote attestation it will be clear that
> the interpreter did not read what was measured.
>
> We just need to run the violation check for the BPRM_CHECK hook too
> (then, probably for us the O_DENY_WRITE flag or alternative solution
> would not be needed, for measurement).
This seems consistent with my interpretation above, but ...
>
> Please, let us know when you apply patches like 2a010c412853 ("fs:
> don't block i_writecount during exec"). We had a discussion [1], but
> probably I missed when it was decided to be applied (I saw now it was
> in the same thread, but didn't get that at the time). We would have
> needed to update our code accordingly. In the future, we will try to
> clarify better our expectations from the VFS.
... I didn't follow this.
Suppose there's some valid contents of /bin/sleep. I execute
/bin/sleep 1m. While it's running, I modify /bin/sleep (by opening it
for write, not by replacing it), and the kernel in question doesn't do
ETXTBSY. Then the sleep process reads (and executes) the modified
contents. Wouldn't a subsequent attestation fail? Why is ETXTBSY
needed?
^ permalink raw reply
* Re: LSM namespacing API
From: Dr. Greg @ 2025-09-01 16:01 UTC (permalink / raw)
To: John Johansen
Cc: Serge E. Hallyn, Stephen Smalley, Paul Moore,
linux-security-module, selinux
In-Reply-To: <6c69fc81-32a7-442c-8c7f-992eda9c2d18@canonical.com>
On Thu, Aug 21, 2025 at 07:57:11AM -0700, John Johansen wrote:
Good morning, I hope the week is starting well for everyone.
Now that everyone is getting past the summer holiday season, it would
seem useful to specifically clarify some of the LSM namespace
implementation details.
> On 8/21/25 07:26, Serge E. Hallyn wrote:
> >On Thu, Aug 21, 2025 at 12:46:10AM -0700, John Johansen wrote:
> >>On 8/19/25 10:47, Stephen Smalley wrote:
> >>>On Tue, Aug 19, 2025 at 10:56???AM Paul Moore <paul@paul-moore.com>
> >>>wrote:
> >>>>
> >>>>Hello all,
> >>>>
> >>>>As most of you are likely aware, Stephen Smalley has been working on
> >>>>adding namespace support to SELinux, and the work has now progressed
> >>>>to the point where a serious discussion on the API is warranted. For
> >>>>those of you are unfamiliar with the details or Stephen's patchset, or
> >>>>simply need a refresher, he has some excellent documentation in his
> >>>>work-in-progress repo:
> >>>>
> >>>>* https://github.com/stephensmalley/selinuxns
> >>>>
> >>>>Stephen also gave a (pre-recorded) presentation at LSS-NA this year
> >>>>about SELinux namespacing, you can watch the presentation here:
> >>>>
> >>>>* https://www.youtube.com/watch?v=AwzGCOwxLoM
> >>>>
> >>>>In the past you've heard me state, rather firmly at times, that I
> >>>>believe namespacing at the LSM framework layer to be a mistake,
> >>>>although if there is something that can be done to help facilitate the
> >>>>namespacing of individual LSMs at the framework layer, I would be
> >>>>supportive of that. I think that a single LSM namespace API, similar
> >>>>to our recently added LSM syscalls, may be such a thing, so I'd like
> >>>>us to have a discussion to see if we all agree on that, and if so,
> >>>>what such an API might look like.
> >>>>
> >>>>At LSS-NA this year, John Johansen and I had a brief discussion where
> >>>>he suggested a single LSM wide clone*(2) flag that individual LSM's
> >>>>could opt into via callbacks. John is directly CC'd on this mail, so
> >>>>I'll let him expand on this idea.
> >>>>
> >>>>While I agree with John that a fs based API is problematic (see all of
> >>>>our discussions around the LSM syscalls), I'm concerned that a single
> >>>>clone*(2) flag will significantly limit our flexibility around how
> >>>>individual LSMs are namespaced, something I don't want to see happen.
> >>>>This makes me wonder about the potential for expanding
> >>>>lsm_set_self_attr(2) to support a new LSM attribute that would support
> >>>>a namespace "unshare" operation, e.g. LSM_ATTR_UNSHARE. This would
> >>>>provide a single LSM framework API for an unshare operation while also
> >>>>providing a mechanism to pass LSM specific via the lsm_ctx struct if
> >>>>needed. Just as we do with the other LSM_ATTR_* flags today,
> >>>>individual LSMs can opt-in to the API fairly easily by providing a
> >>>>setselfattr() LSM callback.
> >>>>
> >>>>Thoughts?
> >>>
> >>>I think we want to be able to unshare a specific security module
> >>>namespace without unsharing the others, i.e. just SELinux or just
> >>>AppArmor.
> >>
> >>yes which is part of the problem with the single flag. That choice
> >>would be entirely at the policy level, without any input from userspace.
> >
> >AIUI Paul's suggestion is the user can pre-set the details of which
> >lsms to unshare and how with the lsm_set_self_attr(), and then a
> >single CLONE_LSM effects that.
> yes, I was specifically addressing the conversation I had with Paul at
> LSS that Paul brought up. That is
>
> At LSS-NA this year, John Johansen and I had a brief discussion where
> he suggested a single LSM wide clone*(2) flag that individual LSM's
> could opt into via callbacks.
>
> the idea there isn't all that different than what Paul proposed. You
> could have a single flag, if you can provide ancillary information. But
> a single flag on its own isn't sufficient.
If one thing has come out of this thread, it would seem to be the fact
that there is going to be little commonality in the requirements that
various LSM's will have for the creation of a namespace.
Given that, the most infrastructure that the LSM should provide would
be a common API for a resource orchestrator to request namespace
separation and to provide a framework for configuring the namespace
prior to when execution begins in the context of the namespace.
The first issue to resolve would seem to be what namespace separation
implies.
John, if I interpret your comments in this discussion correctly, your
contention is that when namespace separation is requested, all of the
LSM's that implement namespaces will create a subordinate namespace,
is that a correct assumption?
It would seem, consistent with the 'stacking' concept, that any LSM
with namespace capability that chooses not to separate, will result in
denial of the separation request. That in turn will imply the need to
unwind or delete any namespace context that other LSM's may have
allocated before the refusal occurred.
This model also implies that the orchestrator requesting the
separation will need to pass a set of parameters describing the
characteristics of each namespace, described by the LSM identifier
that they pertain to. Since there may be a need to configure multiple
namespaces there would be a requirement to pass an array or list of
these parameter sets.
There will also be a need to inject, possibly substantial amounts of
policy or model information into the namespace, before execution in
the context of the namespace begins.
There will also be a need to decide whether namespace separation
should occur at the request of the orchestrator or at the next fork,
the latter model being what the other resource namespaces use. We
believe the argument for direct separation can be made by looking at
the gymnastics that orchestrators need to jump through with the
'change-on-fork' model.
Case in point, it would seem realistic that a process with sufficient
privilege, may desire to place itself in a new LSM namespace context
in a manner that does not require re-execution of itself.
With respect to separation, the remaining issue is if a new security
capability bit needs to be implemented to gate namespace separation.
John, based on your comments, I believe you would support this need?
> You can do a subset with a single flag and only policy directing things,
> but that would cut container managers out of the decision. Without a
> universal container identifier that really limits what you can do. In
> another email I likend it to the MCS label approach to the container
> where you have a single security policy for the container and each
> container gets to be a unique instance of that policy. Its not a perfect
> analogy as with namespace policy can be loaded into the namespace making
> it unique. I don't think the approach is right because not all namespaces
> implement a loadable policy, and even when they do I think we can do a
> better job if the container manager is allowed to provide additional
> context with the namespacing request.
In order to be relevant, the configuration of LSM namespaces need to
be under control of a resource orchestrator or container manager.
What we hear from people doing Kubernetes, at scale, is a desire to be
able to request that a container be run somewhere in the hardware
resource pool and for that container to implement a security model
specific to the needs of the workload running in that container. In a
manner that is orthogonal from other security policies that may be in
effect for other workloads, on the host or in other containers.
Hopefully the above will be of assistance in furthering discussion.
Have a good week.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity
https://github.com/Quixote-Project
^ permalink raw reply
* Re: [RFC PATCH v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK)
From: Roberto Sassu @ 2025-09-01 17:01 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Aleksa Sarai, Mickaël Salaün, Christian Brauner,
Al Viro, Kees Cook, Paul Moore, Serge Hallyn, Arnd Bergmann,
Christian Heimes, Dmitry Vyukov, Elliott Hughes, Fan Wu,
Florian Weimer, Jann Horn, Jeff Xu, Jonathan Corbet,
Jordan R Abrahams, Lakshmi Ramasubramanian, Luca Boccassi,
Matt Bobrowski, Miklos Szeredi, Mimi Zohar, Nicolas Bouchinet,
Robert Waite, Roberto Sassu, Scott Shell, Steve Dower,
Steve Grubb, kernel-hardening, linux-api, linux-fsdevel,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <CALCETrUtJmWxKYSi6QQAGpQR_ETNfoBidCu_VEq8Lx9iJAOyEw@mail.gmail.com>
On Mon, 2025-09-01 at 09:25 -0700, Andy Lutomirski wrote:
> Can you clarify this a bit for those of us who are not well-versed in
> exactly what "measurement" does?
>
> On Mon, Sep 1, 2025 at 2:42 AM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> > > Now, in cases where you have IMA or something and you only permit signed
> > > binaries to execute, you could argue there is a different race here (an
> > > attacker creates a malicious script, runs it, and then replaces it with
> > > a valid script's contents and metadata after the fact to get
> > > AT_EXECVE_CHECK to permit the execution). However, I'm not sure that
> >
> > Uhm, let's consider measurement, I'm more familiar with.
> >
> > I think the race you wanted to express was that the attacker replaces
> > the good script, verified with AT_EXECVE_CHECK, with the bad script
> > after the IMA verification but before the interpreter reads it.
> >
> > Fortunately, IMA is able to cope with this situation, since this race
> > can happen for any file open, where of course a file can be not read-
> > locked.
>
> I assume you mean that this has nothing specifically to do with
> scripts, as IMA tries to protect ordinary (non-"execute" file access)
> as well. Am I right?
Yes, correct, violations are checked for all open() and mmap()
involving regular files. It would not be special to do it for scripts.
> > If the attacker tries to concurrently open the script for write in this
> > race window, IMA will report this event (called violation) in the
> > measurement list, and during remote attestation it will be clear that
> > the interpreter did not read what was measured.
> >
> > We just need to run the violation check for the BPRM_CHECK hook too
> > (then, probably for us the O_DENY_WRITE flag or alternative solution
> > would not be needed, for measurement).
>
> This seems consistent with my interpretation above, but ...
The comment here [1] seems to be clear on why the violation check it is
not done for execution (BPRM_CHECK hook). Since the OS read-locks the
files during execution, this implicitly guarantees that there will not
be concurrent writes, and thus no IMA violations.
However, recently, we took advantage of AT_EXECVE_CHECK to also
evaluate the integrity of scripts (when not executed via ./). Since we
are using the same hook for both executed files (read-locked) and
scripts (I guess non-read-locked), then we need to do a violation check
for BPRM_CHECK too, although it will be redundant for the first
category.
> > Please, let us know when you apply patches like 2a010c412853 ("fs:
> > don't block i_writecount during exec"). We had a discussion [1], but
> > probably I missed when it was decided to be applied (I saw now it was
> > in the same thread, but didn't get that at the time). We would have
> > needed to update our code accordingly. In the future, we will try to
> > clarify better our expectations from the VFS.
>
> ... I didn't follow this.
>
> Suppose there's some valid contents of /bin/sleep. I execute
> /bin/sleep 1m. While it's running, I modify /bin/sleep (by opening it
> for write, not by replacing it), and the kernel in question doesn't do
> ETXTBSY. Then the sleep process reads (and executes) the modified
> contents. Wouldn't a subsequent attestation fail? Why is ETXTBSY
> needed?
Ok, this is actually a good opportunity to explain what it will be
missing. If you do the operations in the order you proposed, actually a
violation will be emitted, because the violating operation is an open()
and the check is done for this system call.
However, if you do the opposite, first open for write and then
execution, IMA will not be aware of that since it trusts the OS to not
make it happen and will not check for violations.
So yes, in your case the remote attestation will fail (actually it is
up to the remote verifier to decide...). But in the opposite case, the
writer could wait for IMA to measure the genuine content and then
modify the content conveniently. The remote attestation will succeed.
Adding the violation check on BPRM_CHECK should be sufficient to avoid
such situation, but I would try to think if there are other
implications for IMA of not read-locking the files on execution.
Roberto
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/integrity/ima/ima_main.c?h=v6.17-rc4#n565
^ permalink raw reply
* Re: LSM namespacing API
From: Casey Schaufler @ 2025-09-01 17:31 UTC (permalink / raw)
To: Dr. Greg, John Johansen
Cc: Serge E. Hallyn, Stephen Smalley, Paul Moore,
linux-security-module, selinux, Casey Schaufler
In-Reply-To: <20250901160102.GA9179@wind.enjellic.com>
On 9/1/2025 9:01 AM, Dr. Greg wrote:
> On Thu, Aug 21, 2025 at 07:57:11AM -0700, John Johansen wrote:
>
> Good morning, I hope the week is starting well for everyone.
>
> Now that everyone is getting past the summer holiday season, it would
> seem useful to specifically clarify some of the LSM namespace
> implementation details.
>
>> On 8/21/25 07:26, Serge E. Hallyn wrote:
>>> On Thu, Aug 21, 2025 at 12:46:10AM -0700, John Johansen wrote:
>>>> On 8/19/25 10:47, Stephen Smalley wrote:
>>>>> On Tue, Aug 19, 2025 at 10:56???AM Paul Moore <paul@paul-moore.com>
>>>>> wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> As most of you are likely aware, Stephen Smalley has been working on
>>>>>> adding namespace support to SELinux, and the work has now progressed
>>>>>> to the point where a serious discussion on the API is warranted. For
>>>>>> those of you are unfamiliar with the details or Stephen's patchset, or
>>>>>> simply need a refresher, he has some excellent documentation in his
>>>>>> work-in-progress repo:
>>>>>>
>>>>>> * https://github.com/stephensmalley/selinuxns
>>>>>>
>>>>>> Stephen also gave a (pre-recorded) presentation at LSS-NA this year
>>>>>> about SELinux namespacing, you can watch the presentation here:
>>>>>>
>>>>>> * https://www.youtube.com/watch?v=AwzGCOwxLoM
>>>>>>
>>>>>> In the past you've heard me state, rather firmly at times, that I
>>>>>> believe namespacing at the LSM framework layer to be a mistake,
>>>>>> although if there is something that can be done to help facilitate the
>>>>>> namespacing of individual LSMs at the framework layer, I would be
>>>>>> supportive of that. I think that a single LSM namespace API, similar
>>>>>> to our recently added LSM syscalls, may be such a thing, so I'd like
>>>>>> us to have a discussion to see if we all agree on that, and if so,
>>>>>> what such an API might look like.
>>>>>>
>>>>>> At LSS-NA this year, John Johansen and I had a brief discussion where
>>>>>> he suggested a single LSM wide clone*(2) flag that individual LSM's
>>>>>> could opt into via callbacks. John is directly CC'd on this mail, so
>>>>>> I'll let him expand on this idea.
>>>>>>
>>>>>> While I agree with John that a fs based API is problematic (see all of
>>>>>> our discussions around the LSM syscalls), I'm concerned that a single
>>>>>> clone*(2) flag will significantly limit our flexibility around how
>>>>>> individual LSMs are namespaced, something I don't want to see happen.
>>>>>> This makes me wonder about the potential for expanding
>>>>>> lsm_set_self_attr(2) to support a new LSM attribute that would support
>>>>>> a namespace "unshare" operation, e.g. LSM_ATTR_UNSHARE. This would
>>>>>> provide a single LSM framework API for an unshare operation while also
>>>>>> providing a mechanism to pass LSM specific via the lsm_ctx struct if
>>>>>> needed. Just as we do with the other LSM_ATTR_* flags today,
>>>>>> individual LSMs can opt-in to the API fairly easily by providing a
>>>>>> setselfattr() LSM callback.
>>>>>>
>>>>>> Thoughts?
>>>>> I think we want to be able to unshare a specific security module
>>>>> namespace without unsharing the others, i.e. just SELinux or just
>>>>> AppArmor.
>>>> yes which is part of the problem with the single flag. That choice
>>>> would be entirely at the policy level, without any input from userspace.
>>> AIUI Paul's suggestion is the user can pre-set the details of which
>>> lsms to unshare and how with the lsm_set_self_attr(), and then a
>>> single CLONE_LSM effects that.
>> yes, I was specifically addressing the conversation I had with Paul at
>> LSS that Paul brought up. That is
>>
>> At LSS-NA this year, John Johansen and I had a brief discussion where
>> he suggested a single LSM wide clone*(2) flag that individual LSM's
>> could opt into via callbacks.
>>
>> the idea there isn't all that different than what Paul proposed. You
>> could have a single flag, if you can provide ancillary information. But
>> a single flag on its own isn't sufficient.
> If one thing has come out of this thread, it would seem to be the fact
> that there is going to be little commonality in the requirements that
> various LSM's will have for the creation of a namespace.
>
> Given that, the most infrastructure that the LSM should provide would
> be a common API for a resource orchestrator to request namespace
> separation and to provide a framework for configuring the namespace
> prior to when execution begins in the context of the namespace.
>
> The first issue to resolve would seem to be what namespace separation
> implies.
>
> John, if I interpret your comments in this discussion correctly, your
> contention is that when namespace separation is requested, all of the
> LSM's that implement namespaces will create a subordinate namespace,
> is that a correct assumption?
>
> It would seem, consistent with the 'stacking' concept, that any LSM
> with namespace capability that chooses not to separate, will result in
> denial of the separation request. That in turn will imply the need to
> unwind or delete any namespace context that other LSM's may have
> allocated before the refusal occurred.
Were it true that 'stacking' rated the status of a 'concept'.
An LSM that is capable of namespacing (the definition of which is
elusive at this time) should be allowed to decline participation
in a namespace creation. That, or there needs to be a convention
for "null" namespaces, by which an LSM can pretend that it isn't
involved in the new namespace. I think the latter smells funny
and would invite "security people don't understand performance"
remarks. No LSM should be allowed to prevent another from using
namespaces.
>
> This model also implies that the orchestrator requesting the
> separation will need to pass a set of parameters describing the
> characteristics of each namespace, described by the LSM identifier
> that they pertain to. Since there may be a need to configure multiple
> namespaces there would be a requirement to pass an array or list of
> these parameter sets.
Just like lsm_set_self_attr(2).
> There will also be a need to inject, possibly substantial amounts of
> policy or model information into the namespace, before execution in
> the context of the namespace begins.
Yup. A major downside of loadable policy.
> There will also be a need to decide whether namespace separation
> should occur at the request of the orchestrator or at the next fork,
> the latter model being what the other resource namespaces use. We
> believe the argument for direct separation can be made by looking at
> the gymnastics that orchestrators need to jump through with the
> 'change-on-fork' model.
>
> Case in point, it would seem realistic that a process with sufficient
> privilege, may desire to place itself in a new LSM namespace context
> in a manner that does not require re-execution of itself.
>
> With respect to separation, the remaining issue is if a new security
> capability bit needs to be implemented to gate namespace separation.
> John, based on your comments, I believe you would support this need?
I don't like the notion of a new capability for this. But then,
I object to almost every new capability proposed. Existing namespaces
don't need their own capabilities. I don't see this case as special.
>
>> You can do a subset with a single flag and only policy directing things,
>> but that would cut container managers out of the decision. Without a
>> universal container identifier that really limits what you can do. In
>> another email I likend it to the MCS label approach to the container
>> where you have a single security policy for the container and each
>> container gets to be a unique instance of that policy. Its not a perfect
>> analogy as with namespace policy can be loaded into the namespace making
>> it unique. I don't think the approach is right because not all namespaces
>> implement a loadable policy, and even when they do I think we can do a
>> better job if the container manager is allowed to provide additional
>> context with the namespacing request.
> In order to be relevant, the configuration of LSM namespaces need to
> be under control of a resource orchestrator or container manager.
I do not approve of kernel features that are pointless without specific
user space support. If it can't be used in ways other than those
defined by a particular user space component they really don't belong
in the kernel.
>
> What we hear from people doing Kubernetes, at scale, is a desire to be
> able to request that a container be run somewhere in the hardware
> resource pool and for that container to implement a security model
> specific to the needs of the workload running in that container. In a
> manner that is orthogonal from other security policies that may be in
> effect for other workloads, on the host or in other containers.
That sounds to me like they want per-container security policy. That
would require that the kernel have the 'concept' of a container. That's
not something I expect to see in my lifetime.
>
> Hopefully the above will be of assistance in furthering discussion.
>
> Have a good week.
>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity
> https://github.com/Quixote-Project
>
^ permalink raw reply
* Re: [PATCH net-next 0/8] ipv4: icmp: Fix source IP derivation in presence of VRFs
From: Jakub Kicinski @ 2025-09-01 18:43 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, pabeni, davem, edumazet, horms, paul, dsahern, petrm,
linux-security-module
In-Reply-To: <aLVb-ujDn_KhOt4V@shredder>
On Mon, 1 Sep 2025 11:40:26 +0300 Ido Schimmel wrote:
> Resolution is below. Please let me know if you prefer that I repost next
> week in order to avoid the conflict.
Yes, please!
--
pw-bot: defer
^ permalink raw reply
* Re: [PATCH net-next 1/8] ipv4: cipso: Simplify IP options handling in cipso_v4_error()
From: David Ahern @ 2025-09-02 2:36 UTC (permalink / raw)
To: Ido Schimmel, netdev
Cc: davem, kuba, pabeni, edumazet, horms, paul, petrm,
linux-security-module
In-Reply-To: <20250901083027.183468-2-idosch@nvidia.com>
On 9/1/25 2:30 AM, Ido Schimmel wrote:
> When __ip_options_compile() is called with an skb, the IP options are
> parsed from the skb data into the provided IP option argument. This is
> in contrast to the case where the skb argument is NULL and the options
> are parsed from opt->__data.
>
> Given that cipso_v4_error() always passes an skb to
> __ip_options_compile(), there is no need to allocate an extra 40 bytes
> (maximum IP options size).
>
> Therefore, simplify the function by removing these extra bytes and make
> the function similar to ipv4_send_dest_unreach() which also calls both
> __ip_options_compile() and __icmp_send().
>
> This is a preparation for changing the arguments being passed to
> __icmp_send().
>
> No functional changes intended.
>
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> net/ipv4/cipso_ipv4.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 2/8] ipv4: icmp: Pass IPv4 control block structure as an argument to __icmp_send()
From: David Ahern @ 2025-09-02 2:36 UTC (permalink / raw)
To: Ido Schimmel, netdev
Cc: davem, kuba, pabeni, edumazet, horms, paul, petrm,
linux-security-module
In-Reply-To: <20250901083027.183468-3-idosch@nvidia.com>
On 9/1/25 2:30 AM, Ido Schimmel wrote:
> __icmp_send() is used to generate ICMP error messages in response to
> various situations such as MTU errors (i.e., "Fragmentation Required")
> and too many hops (i.e., "Time Exceeded").
>
> The skb that generated the error does not necessarily come from the IPv4
> layer and does not always have a valid IPv4 control block in skb->cb.
>
> Therefore, commit 9ef6b42ad6fd ("net: Add __icmp_send helper.") changed
> the function to take the IP options structure as argument instead of
> deriving it from the skb's control block. Some callers of this function
> such as icmp_send() pass the IP options structure from the skb's control
> block as in these call paths the control block is known to be valid, but
> other callers simply pass a zeroed structure.
>
> A subsequent patch will need __icmp_send() to access more information
> from the IPv4 control block (specifically, the ifindex of the input
> interface). As a preparation for this change, change the function to
> take the IPv4 control block structure as an argument instead of the IP
> options structure. This makes the function similar to its IPv6
> counterpart that already takes the IPv6 control block structure as an
> argument.
>
> No functional changes intended.
>
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> include/net/icmp.h | 10 ++++++----
> net/ipv4/cipso_ipv4.c | 12 ++++++------
> net/ipv4/icmp.c | 12 +++++++-----
> net/ipv4/route.c | 10 +++++-----
> 4 files changed, 24 insertions(+), 20 deletions(-)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 3/8] ipv4: icmp: Fix source IP derivation in presence of VRFs
From: David Ahern @ 2025-09-02 2:37 UTC (permalink / raw)
To: Ido Schimmel, netdev
Cc: davem, kuba, pabeni, edumazet, horms, paul, petrm,
linux-security-module
In-Reply-To: <20250901083027.183468-4-idosch@nvidia.com>
On 9/1/25 2:30 AM, Ido Schimmel wrote:
> When the "icmp_errors_use_inbound_ifaddr" sysctl is enabled, the source
> IP of ICMP error messages should be the "primary address of the
> interface that received the packet that caused the icmp error".
>
> The IPv4 ICMP code determines this interface using inet_iif() which in
> the input path translates to skb->skb_iif. If the interface that
> received the packet is a VRF port, skb->skb_iif will contain the ifindex
> of the VRF device and not that of the receiving interface. This is
> because in the input path the VRF driver overrides skb->skb_iif with the
> ifindex of the VRF device itself (see vrf_ip_rcv()).
>
> As such, the source IP that will be chosen for the ICMP error message is
> either an address assigned to the VRF device itself (if present) or an
> address assigned to some VRF port, not necessarily the input or output
> interface.
>
> This behavior is especially problematic when the error messages are
> "Time Exceeded" messages as it means that utilities like traceroute will
> show an incorrect packet path.
>
> Solve this by determining the input interface based on the iif field in
> the control block, if present. This field is set in the input path to
> skb->skb_iif and is not later overridden by the VRF driver, unlike
> skb->skb_iif.
>
> This behavior is consistent with the IPv6 counterpart that already uses
> the iif from the control block.
>
> Reported-by: Andy Roulin <aroulin@nvidia.com>
> Reported-by: Rajkumar Srinivasan <rajsrinivasa@nvidia.com>
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> net/ipv4/icmp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 4/8] selftests: traceroute: Return correct value on failure
From: David Ahern @ 2025-09-02 2:37 UTC (permalink / raw)
To: Ido Schimmel, netdev
Cc: davem, kuba, pabeni, edumazet, horms, paul, petrm,
linux-security-module
In-Reply-To: <20250901083027.183468-5-idosch@nvidia.com>
On 9/1/25 2:30 AM, Ido Schimmel wrote:
> The test always returns success even if some tests were modified to
> fail. Fix by converting the test to use the appropriate library
> functions instead of using its own functions.
>
> Before:
>
> # ./traceroute.sh
> TEST: IPV6 traceroute [FAIL]
> TEST: IPV4 traceroute [ OK ]
>
> Tests passed: 1
> Tests failed: 1
> $ echo $?
> 0
>
> After:
>
> # ./traceroute.sh
> TEST: IPv6 traceroute [FAIL]
> traceroute6 did not return 2000:102::2
> TEST: IPv4 traceroute [ OK ]
> $ echo $?
> 1
>
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> tools/testing/selftests/net/traceroute.sh | 38 ++++++-----------------
> 1 file changed, 9 insertions(+), 29 deletions(-)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 5/8] selftests: traceroute: Use require_command()
From: David Ahern @ 2025-09-02 2:38 UTC (permalink / raw)
To: Ido Schimmel, netdev
Cc: davem, kuba, pabeni, edumazet, horms, paul, petrm,
linux-security-module
In-Reply-To: <20250901083027.183468-6-idosch@nvidia.com>
On 9/1/25 2:30 AM, Ido Schimmel wrote:
> Use require_command() so that the test will return SKIP (4) when a
> required command is not present.
>
> Before:
>
> # ./traceroute.sh
> SKIP: Could not run IPV6 test without traceroute6
> SKIP: Could not run IPV4 test without traceroute
> $ echo $?
> 0
>
> After:
>
> # ./traceroute.sh
> TEST: traceroute6 not installed [SKIP]
> $ echo $?
> 4
>
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> tools/testing/selftests/net/traceroute.sh | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 7/8] selftests: traceroute: Test traceroute with different source IPs
From: David Ahern @ 2025-09-02 2:39 UTC (permalink / raw)
To: Ido Schimmel, netdev
Cc: davem, kuba, pabeni, edumazet, horms, paul, petrm,
linux-security-module
In-Reply-To: <20250901083027.183468-8-idosch@nvidia.com>
On 9/1/25 2:30 AM, Ido Schimmel wrote:
> When generating ICMP error messages, the kernel will prefer a source IP
> that is on the same subnet as the destination IP (see
> inet_select_addr()). Test this behavior by invoking traceroute with
> different source IPs and checking that the ICMP error message is
> generated with a source IP in the same subnet.
>
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> tools/testing/selftests/net/traceroute.sh | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 8/8] selftests: traceroute: Add VRF tests
From: David Ahern @ 2025-09-02 2:40 UTC (permalink / raw)
To: Ido Schimmel, netdev
Cc: davem, kuba, pabeni, edumazet, horms, paul, petrm,
linux-security-module
In-Reply-To: <20250901083027.183468-9-idosch@nvidia.com>
On 9/1/25 2:30 AM, Ido Schimmel wrote:
> Create versions of the existing test cases where the routers generating
> the ICMP error messages are using VRFs. Check that the source IPs of
> these messages do not change in the presence of VRFs.
>
> IPv6 always behaved correctly, but IPv4 fails when reverting "ipv4:
> icmp: Fix source IP derivation in presence of VRFs".
>
> Without IPv4 change:
>
> # ./traceroute.sh
> TEST: IPv6 traceroute [ OK ]
> TEST: IPv6 traceroute with VRF [ OK ]
> TEST: IPv4 traceroute [ OK ]
> TEST: IPv4 traceroute with VRF [FAIL]
> traceroute did not return 1.0.3.1
> $ echo $?
> 1
>
> The test fails because the ICMP error message is sent with the VRF
> device's IP (1.0.4.1):
>
> # traceroute -n -s 1.0.1.3 1.0.2.4
> traceroute to 1.0.2.4 (1.0.2.4), 30 hops max, 60 byte packets
> 1 1.0.4.1 0.165 ms 0.110 ms 0.103 ms
> 2 1.0.2.4 0.098 ms 0.085 ms 0.078 ms
> # traceroute -n -s 1.0.3.3 1.0.2.4
> traceroute to 1.0.2.4 (1.0.2.4), 30 hops max, 60 byte packets
> 1 1.0.4.1 0.201 ms 0.138 ms 0.129 ms
> 2 1.0.2.4 0.123 ms 0.105 ms 0.098 ms
>
> With IPv4 change:
>
> # ./traceroute.sh
> TEST: IPv6 traceroute [ OK ]
> TEST: IPv6 traceroute with VRF [ OK ]
> TEST: IPv4 traceroute [ OK ]
> TEST: IPv4 traceroute with VRF [ OK ]
> $ echo $?
> 0
>
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> tools/testing/selftests/net/traceroute.sh | 178 ++++++++++++++++++++++
> 1 file changed, 178 insertions(+)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* [PATCH] ima: don't clear IMA_DIGSIG flag when setting non-IMA xattr
From: Coiby Xu @ 2025-09-02 4:25 UTC (permalink / raw)
To: linux-integrity
Cc: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn,
open list:SECURITY SUBSYSTEM, open list
Currently when both IMA and EVM are in fix mode, the IMA signature will
be reset to IMA hash if a program first stores IMA signature in
security.ima and then sets security.selinux for a file. For example, on
Fedora, after booting the kernel with "ima_appraise=fix evm=fix
ima_policy=appraise_tcb" and installing rpm-plugin-ima, reinstalling a
package will not make good reference IMA signature generated. Instead
IMA hash is generated,
# getfattr -m - -d -e hex /usr/bin/bash
# file: usr/bin/bash
security.ima=0x0404...
This happens because when setting selinux.selinux, the IMA_DIGSIG flag
that had been set early was cleared. As a result, IMA hash is generated
when the file is closed.
Here's a minimal C reproducer,
#include <stdio.h>
#include <sys/xattr.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
int main() {
const char* file_path = "/usr/sbin/test_binary";
const char* hex_string = "030204d33204490066306402304";
int length = strlen(hex_string);
char* ima_attr_value;
int fd;
fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);
if (fd == -1) {
perror("Error opening file");
return 1;
}
ima_attr_value = (char*)malloc(length / 2 );
for (int i = 0, j = 0; i < length; i += 2, j++) {
sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]);
}
if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) {
perror("Error setting extended attribute");
close(fd);
return 1;
}
const char* selinux_value= "system_u:object_r:bin_t:s0";
if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) {
perror("Error setting extended attribute");
close(fd);
return 1;
}
close(fd);
return 0;
}
Signed-off-by: Coiby Xu <coxu@redhat.com>
---
security/integrity/ima/ima_appraise.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index f435eff4667f..fc82161f8b30 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -708,7 +708,7 @@ static void ima_reset_appraise_flags(struct inode *inode, int digsig)
set_bit(IMA_CHANGE_XATTR, &iint->atomic_flags);
if (digsig)
set_bit(IMA_DIGSIG, &iint->atomic_flags);
- else
+ else if (digsig != -1)
clear_bit(IMA_DIGSIG, &iint->atomic_flags);
}
@@ -794,6 +794,8 @@ static int ima_inode_setxattr(struct mnt_idmap *idmap, struct dentry *dentry,
digsig = (xvalue->type == EVM_IMA_XATTR_DIGSIG);
} else if (!strcmp(xattr_name, XATTR_NAME_EVM) && xattr_value_len > 0) {
digsig = (xvalue->type == EVM_XATTR_PORTABLE_DIGSIG);
+ } else if (result != 1) {
+ digsig = -1;
}
if (result == 1 || evm_revalidate_status(xattr_name)) {
ima_reset_appraise_flags(d_backing_inode(dentry), digsig);
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox