Kernel Hardening

• Thread Index

• Re: [PATCH v2] selinux: check sidtab limit before adding a new entry
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• Re: [PATCH] selinux: convert struct sidtab count to refcount_t
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] selinux: convert struct sidtab count to refcount_t
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2] selinux: check sidtab limit before adding a new entry
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 2/2] kernel-doc: core-api: Include string.h into core-api
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Joe Perches <joe@xxxxxxxxxxx>
• RE: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] selinux: convert struct sidtab count to refcount_t
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• [PATCH V2 2/2] kernel-doc: core-api: Include string.h into core-api
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH V2 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH V2 0/2] string: Add stracpy and stracpy_pad
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH v2] selinux: check sidtab limit before adding a new entry
  • From: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
• Re: [PATCH] selinux: check sidtab limit before adding a new entry
  • From: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
• Re: [PATCH] selinux: check sidtab limit before adding a new entry
  • From: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
• RE: [PATCH v5] Documentation/checkpatch: Prefer strscpy/strscpy_pad over strcpy/strlcpy/strncpy
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• Re: refactor tasklets to avoid unsigned long argument
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] selinux: check sidtab limit before adding a new entry
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• Re: [PATCH] selinux: convert struct sidtab count to refcount_t
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• RE: [PATCH] selinux: convert struct sidtab count to refcount_t
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH 2/2] kernel-doc: core-api: Include string.h into core-api
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH 1/2] string: Add stracpy and stracpy_pad mechanisms
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH 0/2] string: Add stracpy and stracpy_pad
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Jonathan Corbet <corbet@xxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Jonathan Corbet <corbet@xxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Stephen Kitt <steve@xxxxxxx>
• Re: [RFC PATCH] string.h: Add stracpy/stracpy_pad (was: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().)
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [RFC PATCH] string.h: Add stracpy/stracpy_pad (was: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().)
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• Re: [RFC PATCH] string.h: Add stracpy/stracpy_pad (was: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().)
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [RFC PATCH] string.h: Add stracpy/stracpy_pad (was: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().)
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [RFC PATCH] string.h: Add stracpy/stracpy_pad (was: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().)
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH v5] Documentation/checkpatch: Prefer strscpy/strscpy_pad over strcpy/strlcpy/strncpy
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [RFC PATCH] string.h: Add stracpy/stracpy_pad (was: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().)
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v5] Documentation/checkpatch: Prefer strscpy/strscpy_pad over strcpy/strlcpy/strncpy
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: refactor tasklets to avoid unsigned long argument
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Regarding have kfree() (and related) set the pointer to NULL too
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] selinux: check sidtab limit before adding a new entry
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] selinux: check sidtab limit before adding a new entry
  • From: William Roberts <bill.c.roberts@xxxxxxxxx>
• [PATCH] selinux: check sidtab limit before adding a new entry
  • From: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
• Re: [PATCH] selinux: convert struct sidtab count to refcount_t
  • From: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
• [PATCH] selinux: convert struct sidtab count to refcount_t
  • From: NitinGote <nitin.r.gote@xxxxxxxxx>
• [PATCH bpf-next v10 10/10] landlock: Add user and kernel documentation for Landlock
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 09/10] bpf,landlock: Add tests for Landlock
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 08/10] bpf: Add a Landlock sandbox example
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 07/10] landlock: Add ptrace restrictions
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 06/10] bpf,landlock: Add a new map type: inode
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 05/10] landlock: Handle filesystem access control
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 03/10] bpf,landlock: Define an eBPF program type for Landlock hooks
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 01/10] fs,security: Add a new file access type: MAY_CHROOT
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 04/10] seccomp,landlock: Enforce Landlock programs per process hierarchy
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 02/10] bpf: Add expected_attach_triggers and a is_valid_triggers() verifier
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v10 00/10] Landlock LSM: Toward unprivileged sandboxing
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: refactor tasklets to avoid unsigned long argument
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• RE: Regarding have kfree() (and related) set the pointer to NULL too
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• [RFC PATCH 10/10] powerpc/fsl_booke/kaslr: dump out kernel offset information on panic
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 07/10] powerpc/fsl_booke/32: randomize the kernel image offset
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 09/10] powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 06/10] powerpc/fsl_booke/32: implement KASLR infrastructure
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 05/10] powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 04/10] powerpc/fsl_booke/32: introduce create_tlb_entry() helper
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 08/10] powerpc/fsl_booke/kaslr: clear the original kernel if randomized
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 03/10] powerpc: introduce kimage_vaddr to store the kernel base
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 02/10] powerpc: move memstart_addr and kernstart_addr to init-common.c
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 01/10] powerpc: unify definition of M_IF_NEEDED
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [RFC PATCH 00/10] implement KASLR for powerpc/fsl_booke/32
  • From: Jason Yan <yanaijie@xxxxxxxxxx>
• [PATCH v5] Documentation/checkpatch: Prefer strscpy/strscpy_pad over strcpy/strlcpy/strncpy
  • From: NitinGote <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH 2/9] rcu: Add support for consolidated-RCU reader checking (v3)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 2/9] rcu: Add support for consolidated-RCU reader checking (v3)
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH 4/9] ipv4: add lockdep condition to fix for_each_entry (v1)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/9] rcu: Add support for consolidated-RCU reader checking (v3)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 2/9] rcu: Add support for consolidated-RCU reader checking
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 0/9] Harden list_for_each_entry_rcu() and family
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 2/9] rcu: Add support for consolidated-RCU reader checking (v3)
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH 8/9] acpi: Use built-in RCU list checking for acpi_ioremaps list (v1)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 7/9] x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator (v1)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 6/9] workqueue: Convert for_each_wq to use built-in list check (v2)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 5/9] driver/core: Convert to use built-in RCU list checking (v1)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 4/9] ipv4: add lockdep condition to fix for_each_entry (v1)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 2/9] rcu: Add support for consolidated-RCU reader checking (v3)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH 3/9] rcu/sync: Remove custom check for reader-section (v2)
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 2/9] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 2/9] rcu: Add support for consolidated-RCU reader checking
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• [PATCH] rculist: Add build check for single optional list argument
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH 7/9] x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator (v1)
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH 8/9] acpi: Use built-in RCU list checking for acpi_ioremaps list (v1)
  • From: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
• Re: [PATCH 7/9] x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator (v1)
  • From: Bjorn Helgaas <helgaas@xxxxxxxxxx>
• [PATCH 9/9] doc: Update documentation about list_for_each_entry_rcu (v1)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 8/9] acpi: Use built-in RCU list checking for acpi_ioremaps list (v1)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 7/9] x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator (v1)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 6/9] workqueue: Convert for_each_wq to use built-in list check (v2)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 5/9] driver/core: Convert to use built-in RCU list checking (v1)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 4/9] ipv4: add lockdep condition to fix for_each_entry (v1)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 3/9] rcu/sync: Remove custom check for reader-section (v2)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 2/9] rcu: Add support for consolidated-RCU reader checking (v3)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 1/9] rcu/update: Remove useless check for debug_locks (v1)
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 0/9] Harden list_for_each_entry_rcu() and family
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v5 01/12] S.A.R.A.: add documentation
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: [PATCH v5 03/12] S.A.R.A.: cred blob management
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 9/9] doc: Update documentation about list_for_each_entry_rcu
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 8/9] acpi: Use built-in RCU list checking for acpi_ioremaps list
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 7/9] x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 6/9] workqueue: Convert for_each_wq to use built-in list check
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 5/9] driver/core: Convert to use built-in RCU list checking
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 4/9] ipv4: add lockdep condition to fix for_each_entry
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 3/9] rcu/sync: Remove custom check for reader-section
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 2/9] rcu: Add support for consolidated-RCU reader checking
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 1/9] rcu/update: Remove useless check for debug_locks
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v2 0/9] Harden list_for_each_entry_rcu() and family
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• [PATCH 5.2 22/61] Documentation/admin: Remove the vsyscall=native documentation
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 5.1 105/138] Documentation/admin: Remove the vsyscall=native documentation
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.19 66/91] Documentation/admin: Remove the vsyscall=native documentation
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v1 3/6] driver/core: Convert to use built-in RCU list checking
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 0/6] Harden list_for_each_entry_rcu() and family
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v1 6/6] acpi: Use built-in RCU list checking for acpi_ioremaps list
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v1 5/6] x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v1 4/6] workqueue: Convert for_each_wq to use built-in list check
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v1 3/6] driver/core: Convert to use built-in RCU list checking
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v1 2/6] ipv4: add lockdep condition to fix for_each_entry
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v1 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH v1 0/6] Harden list_for_each_entry_rcu() and family
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• Patch "Documentation/admin: Remove the vsyscall=native documentation" has been added to the 5.2-stable tree
  • From: <gregkh@xxxxxxxxxxxxxxxxxxx>
• Patch "Documentation/admin: Remove the vsyscall=native documentation" has been added to the 5.1-stable tree
  • From: <gregkh@xxxxxxxxxxxxxxxxxxx>
• Patch "Documentation/admin: Remove the vsyscall=native documentation" has been added to the 4.19-stable tree
  • From: <gregkh@xxxxxxxxxxxxxxxxxxx>
• RE: [PATCH v4] Added warnings in checkpatch.pl script to :
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• Re: kernel oops loading i915 after "x86/asm: Pin sensitive CR4 bits" (873d50d58)
  • From: "Dmitry V. Levin" <ldv@xxxxxxxxxxxx>
• kernel oops loading i915 after "x86/asm: Pin sensitive CR4 bits" (873d50d58)
  • From: Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
• Re: [PATCH v4] Added warnings in checkpatch.pl script to :
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH v4] Added warnings in checkpatch.pl script to :
  • From: NitinGote <nitin.r.gote@xxxxxxxxx>
• [PATCH v3] Added warnings in checkpatch.pl script to :
  • From: NitinGote <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH v2] Added warnings in checkpatch.pl script to :
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH v2] Added warnings in checkpatch.pl script to :
  • From: NitinGote <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH v5 06/12] S.A.R.A.: WX protection
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v8 11/11] x86/alternatives: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 10/11] x86/paravirt: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 09/11] x86/power/64: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 08/11] x86/boot/64: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 07/11] x86/acpi: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 06/11] x86/CPU: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 05/11] x86: pm-trace - Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 04/11] x86/entry/64: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 03/11] x86: relocate_kernel - Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 02/11] x86: Add macro to get symbol address for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 01/11] x86/crypto: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v8 00/11] x86: PIE support to extend KASLR randomization
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• Re: [PATCH v5 04/12] S.A.R.A.: generic DFA for string matching
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH v2] powerpc/mm: Implement STRICT_MODULE_RWX
  • From: "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx>
• RE: [PATCH v5 06/12] S.A.R.A.: WX protection
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [PATCH v5 11/12] S.A.R.A.: /proc/*/mem write limitation
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• Re: [PATCH v5 04/12] S.A.R.A.: generic DFA for string matching
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• Re: [PATCH v5 06/12] S.A.R.A.: WX protection
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• Re: [PATCH v5 00/12] S.A.R.A. a new stacked LSM
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Stephen Kitt <steve@xxxxxxx>
• Re: [PATCH v5 00/12] S.A.R.A. a new stacked LSM
  • From: James Morris <jmorris@xxxxxxxxx>
• RE: Regarding have kfree() (and related) set the pointer to NULL too
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH v5 06/12] S.A.R.A.: WX protection
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v5 04/12] S.A.R.A.: generic DFA for string matching
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH v5 11/12] S.A.R.A.: /proc/*/mem write limitation
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH v5 01/12] S.A.R.A.: add documentation
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• Re: [PATCH v5 01/12] S.A.R.A.: add documentation
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• Re: [PATCH v5 06/12] S.A.R.A.: WX protection
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• Re: [PATCH v5 08/12] S.A.R.A.: trampoline emulation
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• Re: [PATCH v5 02/12] S.A.R.A.: create framework
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• Re: [PATCH v5 00/12] S.A.R.A. a new stacked LSM
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• Re: [PATCH v5 00/12] S.A.R.A. a new stacked LSM
  • From: Jordan Glover <Golden_Miller83@xxxxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Stephen Kitt <steve@xxxxxxx>
• [PATCH v5 12/12] MAINTAINERS: take maintainership for S.A.R.A.
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 10/12] S.A.R.A.: XATTRs support
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 11/12] S.A.R.A.: /proc/*/mem write limitation
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 09/12] S.A.R.A.: WX protection procattr interface
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 08/12] S.A.R.A.: trampoline emulation
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 07/12] LSM: creation of "pagefault_handler" LSM hook
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 06/12] S.A.R.A.: WX protection
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 05/12] LSM: creation of "check_vmflags" LSM hook
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 04/12] S.A.R.A.: generic DFA for string matching
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 03/12] S.A.R.A.: cred blob management
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 02/12] S.A.R.A.: create framework
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 01/12] S.A.R.A.: add documentation
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• [PATCH v5 00/12] S.A.R.A. a new stacked LSM
  • From: Salvatore Mesoraca <s.mesoraca16@xxxxxxxxx>
• Re: [PATCH v10 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [RFC PATCH] string.h: Add stracpy/stracpy_pad (was: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().)
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH v10 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Nitin Gote <nitin.r.gote@xxxxxxxxx>
• Re: refactor tasklets to avoid unsigned long argument
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2] checkpatch: Added warnings in favor of strscpy().
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: refactor tasklets to avoid unsigned long argument
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: [PATCH v10 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v2] checkpatch: Added warnings in favor of strscpy().
  • From: Nitin Gote <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH v10 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: refactor tasklets to avoid unsigned long argument
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• refactor tasklets to avoid unsigned long argument
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: [PATCH v2] Convert struct pid count to refcount_t
  • From: Joel Fernandes <joelaf@xxxxxxxxxx>
• Re: [PATCH v2] Convert struct pid count to refcount_t
  • From: kbuild test robot <lkp@xxxxxxxxx>
• [PATCH v3] Convert struct pid count to refcount_t
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] Convert struct pid count to refcount_t
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] Convert struct pid count to refcount_t
  • From: Jann Horn <jannh@xxxxxxxxxx>
• RE: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Stephen Kitt <steve@xxxxxxx>
• Re: [PATCH RFC v2] Convert struct pid count to refcount_t
  • From: Andrea Parri <andrea.parri@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Alexey Dobriyan <adobriyan@xxxxxxxxx>
• Re: [PATCH v2] Convert struct pid count to refcount_t
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v2] Convert struct pid count to refcount_t
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH bpf-next v9 05/10] bpf,landlock: Add a new map type: inode
  • From: Mickaël Salaün <mickael.salaun@xxxxxxxxxxx>
• [PATCH] checkpatch: Added warnings in favor of strscpy().
  • From: Nitin Gote <nitin.r.gote@xxxxxxxxx>
• [PATCH v10 2/2] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v10 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v10 0/3] add init_on_alloc/init_on_free boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [tip:x86/entry] selftests/x86: Add a test for process_vm_readv() on the vsyscall page
  • From: tip-bot for Andy Lutomirski <tipbot@xxxxxxxxx>
• [tip:x86/entry] x86/vsyscall: Add __ro_after_init to global variables
  • From: tip-bot for Andy Lutomirski <tipbot@xxxxxxxxx>
• [tip:x86/entry] x86/vsyscall: Change the default vsyscall mode to xonly
  • From: tip-bot for Andy Lutomirski <tipbot@xxxxxxxxx>
• [tip:x86/entry] selftests/x86/vsyscall: Verify that vsyscall=none blocks execution
  • From: tip-bot for Andy Lutomirski <tipbot@xxxxxxxxx>
• [tip:x86/entry] x86/vsyscall: Document odd SIGSEGV error code for vsyscalls
  • From: tip-bot for Andy Lutomirski <tipbot@xxxxxxxxx>
• [tip:x86/entry] x86/vsyscall: Add a new vsyscall=xonly mode
  • From: tip-bot for Andy Lutomirski <tipbot@xxxxxxxxx>
• [tip:x86/entry] Documentation/admin: Remove the vsyscall=native documentation
  • From: tip-bot for Andy Lutomirski <tipbot@xxxxxxxxx>
• Re: [PATCH v9 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: [PATCH v2 8/8] selftests/x86: Add a test for process_vm_readv() on the vsyscall page
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 7/8] x86/vsyscall: Add __ro_after_init to global variables
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 6/8] x86/vsyscall: Change the default vsyscall mode to xonly
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 5/8] selftests/x86/vsyscall: Verify that vsyscall=none blocks execution
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 4/8] x86/vsyscall: Document odd SIGSEGV error code for vsyscalls
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 2/8] x86/vsyscall: Add a new vsyscall=xonly mode
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 1/8] x86/vsyscall: Remove the vsyscall=native documentation
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Archive kernel-hardening@xxxxxxxxxxxxxxxxxx on lore.kernel.org too
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH bpf-next v9 05/10] bpf,landlock: Add a new map type: inode
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: Archive kernel-hardening@xxxxxxxxxxxxxxxxxx on lore.kernel.org too
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• Re: [PATCH v9 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Qian Cai <cai@xxxxxx>
• Re: [PATCH v9 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Regarding have kfree() (and related) set the pointer to NULL too
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH bpf-next v9 05/10] bpf,landlock: Add a new map type: inode
  • From: Mickaël Salaün <mickael.salaun@xxxxxxxxxxx>
• Fwd: Audit and fix all misuse of NLA_STRING: STATUS
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: [PATCH v9 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v9 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Qian Cai <cai@xxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v9 2/2] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v9 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v9 0/3] add init_on_alloc/init_on_free boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: Regarding have kfree() (and related) set the pointer to NULL too
  • From: Vegard Nossum <vegard.nossum@xxxxxxxxx>
• Re: Regarding have kfree() (and related) set the pointer to NULL too
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH v2 7/8] x86/vsyscall: Add __ro_after_init to global variables
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 8/8] selftests/x86: Add a test for process_vm_readv() on the vsyscall page
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 6/8] x86/vsyscall: Change the default vsyscall mode to xonly
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 5/8] selftests/x86/vsyscall: Verify that vsyscall=none blocks execution
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 4/8] x86/vsyscall: Document odd SIGSEGV error code for vsyscalls
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 2/8] x86/vsyscall: Add a new vsyscall=xonly mode
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 1/8] x86/vsyscall: Remove the vsyscall=native documentation
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Audit and fix all misuse of NLA_STRING: STATUS
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC v2] Convert struct pid count to refcount_t
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Qian Cai <cai@xxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• [PATCH v8 2/2] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v8 0/3] add init_on_alloc/init_on_free boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v8 0/3] add init_on_alloc/init_on_free boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH bpf-next v9 02/10] bpf: Add eBPF program subtype and is_valid_subtype() verifier
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH bpf-next v9 02/10] bpf: Add eBPF program subtype and is_valid_subtype() verifier
  • From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
• Re: [PATCH bpf-next v9 05/10] bpf,landlock: Add a new map type: inode
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• [PATCH bpf-next v9 01/10] fs,security: Add a new file access type: MAY_CHROOT
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 03/10] bpf,landlock: Define an eBPF program type for Landlock hooks
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 08/10] bpf: Add a Landlock sandbox example
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 06/10] landlock: Handle filesystem access control
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 00/10] Landlock LSM: Toward unprivileged sandboxing
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 02/10] bpf: Add eBPF program subtype and is_valid_subtype() verifier
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 09/10] bpf,landlock: Add tests for Landlock
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 10/10] landlock: Add user and kernel documentation for Landlock
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 04/10] seccomp,landlock: Enforce Landlock programs per process hierarchy
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 05/10] bpf,landlock: Add a new map type: inode
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH bpf-next v9 07/10] landlock: Add ptrace restrictions
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Archive kernel-hardening@xxxxxxxxxxxxxxxxxx on lore.kernel.org too
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• Re: Archive kernel-hardening@xxxxxxxxxxxxxxxxxx on lore.kernel.org too
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Archive kernel-hardening@xxxxxxxxxxxxxxxxxx on lore.kernel.org too
  • From: Solar Designer <solar@xxxxxxxxxxxx>
• Re: Audit and fix all misuse of NLA_STRING: STATUS
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: [PATCH v6 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH RFC v2] Convert struct pid count to refcount_t
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Archive kernel-hardening@xxxxxxxxxxxxxxxxxx on lore.kernel.org too
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• Re: [PATCH RFC v2] Convert struct pid count to refcount_t
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC v2] Convert struct pid count to refcount_t
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH RFC v2] Convert struct pid count to refcount_t
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• [PATCH RFC v2] Convert struct pid count to refcount_t
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: "Denis 'GNUtoo' Carikli" <GNUtoo@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Qian Cai <cai@xxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Qian Cai <cai@xxxxxx>
• Re: Audit and fix all misuse of NLA_STRING: STATUS
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v6 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Audit and fix all misuse of NLA_STRING: STATUS
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• RE: Get involved
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Andrea Parri <andrea.parri@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Solar Designer <solar@xxxxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Daniel Vetter <daniel@xxxxxxxx>
• Re: [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
  • From: Daniel Axtens <dja@xxxxxxxxxx>
• Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Thierry Reding <thierry.reding@xxxxxxxxx>
• [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx>
• [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir
  • From: Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx>
• [PATCH v1 01/22] docs: Documentation/*.txt: rename all ReST files to *.rst
  • From: Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx>
• Audit and fix all misuse of NLA_STRING: STATUS
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: [PATCH v3 3/3] x86/asm: Pin sensitive CR0 bits
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v3 3/3] x86/asm: Pin sensitive CR0 bits
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: Get involved
  • From: Jann Horn <jannh@xxxxxxxxxx>
• RE: Get involved
  • From: "Gote, Nitin R" <nitin.r.gote@xxxxxxxxx>
• Re: [PATCH v3 3/3] x86/asm: Pin sensitive CR0 bits
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH v3 1/3] lkdtm: Check for SMEP clearing protections
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v3 1/3] lkdtm: Check for SMEP clearing protections
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 1/3] lkdtm: Check for SMEP clearing protections
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 2/3] x86/asm: Pin sensitive CR4 bits
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 0/3] x86/asm: Pin sensitive CR4 and CR0 bits
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 3/3] x86/asm: Pin sensitive CR0 bits
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Nadav Amit <nadav.amit@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Nadav Amit <nadav.amit@xxxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• [PATCH v7 2/2] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v7 0/3] add init_on_alloc/init_on_free boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Alexander Graf <graf@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: "Denis 'GNUtoo' Carikli" <GNUtoo@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: "Denis 'GNUtoo' Carikli" <GNUtoo@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: Jann Horn <jannh@xxxxxxxxxx>
• [PATCH] security: do not enable CONFIG_GCC_PLUGINS by default
  • From: "Denis 'GNUtoo' Carikli" <GNUtoo@xxxxxxxxxxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• [PATCH v2] powerpc/mm: Implement STRICT_MODULE_RWX
  • From: Russell Currey <ruscur@xxxxxxxxxx>
• Re: [PATCH 5/5] x86/vsyscall: Change the default vsyscall mode to xonly
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
• Re: [PATCH 5/5] x86/vsyscall: Change the default vsyscall mode to xonly
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH 2/5] x86/vsyscall: Add a new vsyscall=xonly mode
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH 3/5] x86/vsyscall: Document odd #PF's error code for vsyscalls
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Nadav Amit <namit@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• [PATCH 4/3] binfmt/elf: don't expose prandom_u32() state
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• [PATCH 3/3] binfmt/elf: randomize padding between ELF interp info
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• [PATCH 2/3] binfmt/elf: align AT_RANDOM array
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• [PATCH 1/3] binfmt/elf: use functions for stack manipulation
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• [PATCH 0/3] ELF interpretor info: align and add random padding
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Liran Alon <liran.alon@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Alexander Graf <graf@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Alexander Graf <graf@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Alexander Graf <graf@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Nadav Amit <namit@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
• [RFC 10/10] kvm, x86: move guest FPU state into process local memory
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 09/10] kvm, vmx: move gprs to process local memory
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 08/10] kvm, vmx: move register clearing out of assembly path
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 07/10] kvm, vmx: move CR2 context switch out of assembly path
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 06/10] kvm/x86: add support for storing vCPU state in process-local memory
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 05/10] mm: allocate/release physical pages for process-local memory
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 04/10] mm: allocate virtual space for process-local memory
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 03/10] x86/mm, mm,kernel: add teardown for process-local memory to mm cleanup
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 02/10] x86/speculation, mm: add process local virtual memory region
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 01/10] x86/mm/kaslr: refactor to use enum indices for regions
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• [RFC 00/10] Process-local memory allocations for hiding KVM secrets
  • From: Marius Hillenbrand <mhillenb@xxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Shyam Saini <mayhs11saini@xxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Shyam Saini <mayhs11saini@xxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro
  • From: Shyam Saini <shyam.saini@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v7 10/12] x86/power/64: Adapt assembly for PIE support
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 08/12] x86/acpi: Adapt assembly for PIE support
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 09/12] x86/boot/64: Adapt assembly for PIE support
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 06/12] x86: pm-trace - Adapt assembly for PIE support
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 05/12] x86/entry/64: Adapt assembly for PIE support
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 04/12] x86: relocate_kernel - Adapt assembly for PIE support
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 00/12] x86: PIE support to extend KASLR randomization
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 5/5] x86/vsyscall: Change the default vsyscall mode to xonly
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 2/5] x86/vsyscall: Add a new vsyscall=xonly mode
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 3/5] x86/vsyscall: Document odd #PF's error code for vsyscalls
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH 5/5] x86/vsyscall: Change the default vsyscall mode to xonly
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH 4/5] selftests/x86/vsyscall: Verify that vsyscall=none blocks execution
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH 3/5] x86/vsyscall: Document odd #PF's error code for vsyscalls
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH 2/5] x86/vsyscall: Add a new vsyscall=xonly mode
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH 1/5] x86/vsyscall: Remove the vsyscall=native documentation
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Regarding add detection for double-reads
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Regarding add detection for double-reads
  • From: "Khajapasha, Mohammed" <mohammed.khajapasha@xxxxxxxxx>
• Re: Get involved
  • From: Shyam Saini <mayhs11saini@xxxxxxxxx>
• Re: Get involved
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: Get involved
  • From: Shyam Saini <mayhs11saini@xxxxxxxxx>
• Re: Get involved
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Get involved
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: Get involved
  • From: Shyam Saini <mayhs11saini@xxxxxxxxx>
• Re: Get involved
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• [PATCH 5.1 85/85] x86/kprobes: Set instruction page as executable
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.19 69/73] x86/kprobes: Set instruction page as executable
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.19 68/73] x86/ftrace: Set trampoline pages as executable
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v6 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v6 3/3] lib: introduce test_meminit module
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v6 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v6 3/3] lib: introduce test_meminit module
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v6 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v6 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [RFC 4/6] workqueue: Convert for_each_wq to use built-in list check
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] lib/test_stackinit: Handle Clang auto-initialization pattern
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH] lib/test_stackinit: Handle Clang auto-initialization pattern
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Kaiwan N Billimoria <kaiwan@xxxxxxxxxxxxxx>
• Re: [RFC 4/6] workqueue: Convert for_each_wq to use built-in list check
  • From: Daniel Jordan <daniel.m.jordan@xxxxxxxxxx>
• Re: [RFC 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [RFC 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Get involved
  • From: Romain Perier <romain.perier@xxxxxxxxx>
• Re: [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [RFC 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: [RFC 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• Re: [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Kaiwan N Billimoria <kaiwan@xxxxxxxxxxxxxx>
• Re: [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
  • From: Andrew Donnellan <ajd@xxxxxxxxxxxxx>
• Re: [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
  • From: Christopher M Riedl <cmr@xxxxxxxxxxxxxx>
• Re: [RFC 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [RFC 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [RFC 2/6] ipv4: add lockdep condition to fix for_each_entry
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
  • From: Andrew Donnellan <ajd@xxxxxxxxxxxxx>
• Re: [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [RFC 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [RFC 2/6] ipv4: add lockdep condition to fix for_each_entry
  • From: Pavel Machek <pavel@xxxxxxx>
• Re: [RFC 2/6] ipv4: add lockdep condition to fix for_each_entry
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [RFC 2/6] ipv4: add lockdep condition to fix for_each_entry
  • From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
• Re: [RFC 2/6] ipv4: add lockdep condition to fix for_each_entry
  • From: Pavel Machek <pavel@xxxxxxx>
• [RFC 6/6] acpi: Use built-in RCU list checking for acpi_ioremaps list
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [RFC 5/6] x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [RFC 4/6] workqueue: Convert for_each_wq to use built-in list check
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [RFC 3/6] driver/core: Convert to use built-in RCU list checking
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [RFC 2/6] ipv4: add lockdep condition to fix for_each_entry
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [RFC 1/6] rcu: Add support for consolidated-RCU reader checking
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [RFC 0/6] Harden list_for_each_entry_rcu() and family
  • From: "Joel Fernandes (Google)" <joel@xxxxxxxxxxxxxxxxx>
• [PATCH AUTOSEL 5.0 034/173] gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.1 037/186] gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• Re: [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 4.19 079/276] x86/modules: Avoid breaking W^X while loading modules
  • From: Nadav Amit <namit@xxxxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: unrecognizable insn generated in plugin?
  • From: Tycho Andersen <tycho@xxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: unrecognizable insn generated in plugin?
  • From: Mark Brand <markbrand@xxxxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 4.19 079/276] x86/modules: Avoid breaking W^X while loading modules
  • From: Pavel Machek <pavel@xxxxxxx>
• Re: unrecognizable insn generated in plugin?
  • From: Tycho Andersen <tycho@xxxxxxxx>
• Re: unrecognizable insn generated in plugin?
  • From: Andrew Pinski <pinskia@xxxxxxxxx>
• unrecognizable insn generated in plugin?
  • From: Tycho Andersen <tycho@xxxxxxxx>
• [PATCH tip/core/rcu 3/4] module: Make srcu_struct ptr array as read-only
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx>
• [PATCH 4.19 079/276] x86/modules: Avoid breaking W^X while loading modules
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 5.0 086/346] x86/modules: Avoid breaking W^X while loading modules
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 5.0 079/346] x86/ftrace: Set trampoline pages as executable
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 5.1 095/405] x86/modules: Avoid breaking W^X while loading modules
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 5.1 088/405] x86/ftrace: Set trampoline pages as executable
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH v5 3/3] lib: introduce test_meminit module
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v5 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH v7 11/12] x86/paravirt: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• Re: [PATCH v7 01/12] x86/crypto: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v5 3/3] lib: introduce test_meminit module
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v5 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v5 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v7 11/12] x86/paravirt: Adapt assembly for PIE support
  • From: Juergen Gross <jgross@xxxxxxxx>
• [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
  • From: "Christopher M. Riedl" <cmr@xxxxxxxxxxxxxx>
• Re: [PATCH v4 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v4 3/3] lib: introduce test_meminit module
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v4 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v4 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v4 0/3] RFC: add init_on_alloc/init_on_free boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH 3/3] lib: introduce test_meminit module
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH 2/3] mm: init: report memory auto-initialization features at boot time
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v3 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v3 0/3] RFC: add init_on_alloc/init_on_free boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v3 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v7 01/12] x86/crypto: Adapt assembly for PIE support
  • From: Eric Biggers <ebiggers@xxxxxxxxxx>
• Re: [PATCH v7 01/12] x86/crypto: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH AUTOSEL 4.19 039/244] x86/modules: Avoid breaking W^X while loading modules
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.1 055/375] x86/modules: Avoid breaking W^X while loading modules
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.1 048/375] x86/ftrace: Set trampoline pages as executable
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.0 048/317] x86/modules: Avoid breaking W^X while loading modules
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.0 041/317] x86/ftrace: Set trampoline pages as executable
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• Re: [PATCH v7 03/12] x86: Add macro to get symbol address for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• Re: Sparse context checking Vs Clang Thread Safety analysis
  • From: Himanshu Jha <himanshujha199640@xxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v7 01/12] x86/crypto: Adapt assembly for PIE support
  • From: Eric Biggers <ebiggers@xxxxxxxxxx>
• Re: [PATCH v7 03/12] x86: Add macro to get symbol address for PIE support
  • From: hpa@xxxxxxxxx
• Re: [PATCH v7 02/12] x86: Use symbol name in jump table for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxx>
• [PATCH v7 12/12] x86/alternatives: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 11/12] x86/paravirt: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 10/12] x86/power/64: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 09/12] x86/boot/64: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 08/12] x86/acpi: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 07/12] x86/CPU: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 06/12] x86: pm-trace - Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 05/12] x86/entry/64: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 04/12] x86: relocate_kernel - Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 03/12] x86: Add macro to get symbol address for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 02/12] x86: Use symbol name in jump table for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 01/12] x86/crypto: Adapt assembly for PIE support
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• [PATCH v7 00/12] x86: PIE support to extend KASLR randomization
  • From: Thomas Garnier <thgarnie@xxxxxxxxxxxx>
• Re: Sparse context checking Vs Clang Thread Safety analysis
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH 5/4] mm: Introduce SLAB_NO_FREE_INIT and mark excluded caches
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 5/4] mm: Introduce SLAB_NO_FREE_INIT and mark excluded caches
  • From: Mathias Krause <minipli@xxxxxxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v2 2/4] lib: introduce test_meminit module
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 4/4] net: apply __GFP_NO_AUTOINIT to AF_UNIX sk_buff allocations
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 5/4] mm: Introduce SLAB_NO_FREE_INIT and mark excluded caches
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 2/4] lib: introduce test_meminit module
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v2 4/4] net: apply __GFP_NO_AUTOINIT to AF_UNIX sk_buff allocations
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v2 4/4] net: apply __GFP_NO_AUTOINIT to AF_UNIX sk_buff allocations
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH 5/4] mm: Introduce SLAB_NO_FREE_INIT and mark excluded caches
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH 5/4] mm: Introduce SLAB_NO_FREE_INIT and mark excluded caches
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 4/4] net: apply __GFP_NO_AUTOINIT to AF_UNIX sk_buff allocations
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 4/4] net: apply __GFP_NO_AUTOINIT to AF_UNIX sk_buff allocations
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH v2 2/4] lib: introduce test_meminit module
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 3/4] gfp: mm: introduce __GFP_NOINIT
  • From: Souptick Joarder <jrdr.linux@xxxxxxxxx>
• [PATCH v2 4/4] net: apply __GFP_NO_AUTOINIT to AF_UNIX sk_buff allocations
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v2 2/4] lib: introduce test_meminit module
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v2 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• [PATCH v2 0/4] RFC: add init_on_alloc/init_on_free boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH 3/4] gfp: mm: introduce __GFP_NOINIT
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH 3/4] gfp: mm: introduce __GFP_NOINIT
  • From: Souptick Joarder <jrdr.linux@xxxxxxxxx>
• Re: [PATCH] gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6
  • From: Doug Anderson <dianders@xxxxxxxxxxxx>
• Re: [PATCH] gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH] gcc-plugins: arm_ssp_per_task_plugin: Fix for older GCC < 6
  • From: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 0/7] crypto: x86: Fix indirect function call casts
  • From: Sami Tolvanen <samitolvanen@xxxxxxxxxx>
• Re: [PATCH v3 0/7] crypto: x86: Fix indirect function call casts
  • From: Eric Biggers <ebiggers@xxxxxxxxxx>
• Re: [PATCH 1/4] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v3 0/7] crypto: x86: Fix indirect function call casts
  • From: Sami Tolvanen <samitolvanen@xxxxxxxxxx>
• Re: [PATCH 3/4] gfp: mm: introduce __GFP_NOINIT
  • From: Alexander Potapenko <glider@xxxxxxxxxx>
• Re: [PATCH v3 0/7] crypto: x86: Fix indirect function call casts
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>