Kernel Hardening

• Thread Index

• [PATCH] sched/topology: change kzalloc to kcalloc
  • From: Ethan Carter Edwards <ethan@xxxxxxxxxxxxxxxxx>
• [PATCH] dm: change kzalloc to kcalloc
  • From: Ethan Carter Edwards <ethan@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] dm: change kzalloc to kcalloc
  • From: "Gustavo A. R. Silva" <gustavo@xxxxxxxxxxxxxx>
• [PATCH v2] thermal/debugfs: change kzalloc to kcalloc
  • From: Ethan Carter Edwards <ethan@xxxxxxxxxxxxxxxxx>
• [PATCH] thermal/debugfs: change kzalloc to kcalloc
  • From: Ethan Carter Edwards <ethan@xxxxxxxxxxxxxxxxx>
• Re: Help Needed: Debugging Memory Corruption results GPF
  • From: jim.cromie@xxxxxxxxx
• Re: [PATCH v23 0/8] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v23 0/8] Script execution control (was O_MAYEXEC)
  • From: Kees Cook <kees@xxxxxxxxxx>
• Re: [PATCH v23 0/8] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 8/8] ima: instantiate the bprm_creds_for_exec() hook
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 7/8] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 6/8] selftests: ktap_helpers: Fix uninitialized variable
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 5/8] samples/check-exec: Add set-exec
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 4/8] selftests/landlock: Add tests for execveat + AT_EXECVE_CHECK
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 3/8] selftests/exec: Add 32 tests for AT_EXECVE_CHECK and exec securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 2/8] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 1/8] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v23 0/8] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v22 2/8] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxxxx>
• Re: [PATCH v22 1/8] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxxxx>
• Re: [PATCH v22 0/8] Script execution control (was O_MAYEXEC)
  • From: jeffxu <jeffxu@xxxxxxxxxxxx>
• Re: [PATCH v22 8/8] ima: instantiate the bprm_creds_for_exec() hook
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• Re: [PATCH v22 2/8] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v22 0/8] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 8/8] ima: instantiate the bprm_creds_for_exec() hook
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 7/8] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 6/8] selftests: ktap_helpers: Fix uninitialized variable
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 5/8] samples/check-exec: Add set-exec
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 4/8] selftests/landlock: Add tests for execveat + AT_EXECVE_CHECK
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 3/8] selftests/exec: Add 32 tests for AT_EXECVE_CHECK and exec securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 2/8] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 1/8] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v22 0/8] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• Re: [PATCH v21 6/6] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [PATCH v21 6/6] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v21 6/6] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [PATCH v21 6/6] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v21 6/6] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v21 0/6] Script execution control (was O_MAYEXEC)
  • From: Kees Cook <kees@xxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxxxx>
• Re: [PATCH v21 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v21 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxxxx>
• Re: [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxxxx>
• Re: [RFCv1 0/6] Page Detective
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• Re: [RFCv1 0/6] Page Detective
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [RFCv1 0/6] Page Detective
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [RFCv1 0/6] Page Detective
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [RFCv1 0/6] Page Detective
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [RFCv1 0/6] Page Detective
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [RFCv1 0/6] Page Detective
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [RFCv1 0/6] Page Detective
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Help Needed: Debugging Memory Corruption results GPF
  • From: Muni Sekhar <munisekharrms@xxxxxxxxx>
• [PATCH v21 6/6] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v21 5/6] samples/check-exec: Add set-exec
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v21 4/6] selftests/landlock: Add tests for execveat + AT_EXECVE_CHECK
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v21 3/6] selftests/exec: Add 32 tests for AT_EXECVE_CHECK and exec securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v21 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v21 1/6] exec: Add a new AT_EXECVE_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v21 0/6] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: sergeh@xxxxxxxxxx
• Re: [PATCH v20 1/6] exec: Add a new AT_CHECK flag to execveat(2)
  • From: sergeh@xxxxxxxxxx
• Re: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: sergeh@xxxxxxxxxx
• Re: [PATCH v20 1/6] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Amir Goldstein <amir73il@xxxxxxxxx>
• Re: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v20 1/6] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v20 1/6] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v20 1/6] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Amir Goldstein <amir73il@xxxxxxxxx>
• Re: [PATCH v20 1/6] exec: Add a new AT_CHECK flag to execveat(2)
  • From: "Serge E. Hallyn" <serge@xxxxxxxxxx>
• Re: [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: "Serge E. Hallyn" <serge@xxxxxxxxxx>
• [PATCH v20 6/6] samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v20 5/6] samples/check-exec: Add set-exec
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v20 4/6] selftests/landlock: Add tests for execveat + AT_CHECK
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v20 3/6] selftests/exec: Add 32 tests for AT_CHECK and exec securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v20 2/6] security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v20 1/6] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v20 0/6] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: "Jarkko Sakkinen" <jarkko@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: enh <enh@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Boris Lukashev <rageltman@xxxxxxxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Steve Dower <steve.dower@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Boris Lukashev <blukashev@xxxxxxxxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Steve Dower <steve.dower@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Jonathan Corbet <corbet@xxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Steve Dower <steve.dower@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Kees Cook <kees@xxxxxxxxxx>
• Re: [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC (was: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2))
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 5/5] samples/should-exec: Add set-should-exec
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Steve Dower <steve.dower@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxx>
• Re: [RFC PATCH v19 5/5] samples/should-exec: Add set-should-exec
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Kees Cook <kees@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Jeff Xu <jeffxu@xxxxxxxxxx>
• [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC (was: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2))
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: "Jarkko Sakkinen" <jarkko@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: "Jarkko Sakkinen" <jarkko@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Kees Cook <kees@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Kees Cook <kees@xxxxxxxxxx>
• Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Kees Cook <kees@xxxxxxxxxx>
• [RFC PATCH v19 5/5] samples/should-exec: Add set-should-exec
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [RFC PATCH v19 4/5] selftests/landlock: Add tests for execveat + AT_CHECK
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [RFC PATCH v19 3/5] selftests/exec: Add tests for AT_CHECK and related securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v2 00/19] PKS write protected page tables
  • From: Boris Lukashev <blukashev@xxxxxxxxxxxxxxxx>
• Re: [RFC PATCH v2 00/19] PKS write protected page tables
  • From: Boris Lukashev <blukashev@xxxxxxxxxxxxxxxx>
• Re: [RFC PATCH v2 00/19] PKS write protected page tables
  • From: Ira Weiny <ira.weiny@xxxxxxxxx>
• Re: [RFC PATCH v2 00/19] PKS write protected page tables
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [RFC PATCH v2 00/19] PKS write protected page tables
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [ANNOUNCE] CFP: Linux Security Summit Europe 2024
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• [ANNOUNCE] CFP: Linux Security Summit North America 2024
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Stefan Bavendiek <stefan.bavendiek@xxxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: "Serge E. Hallyn" <serge@xxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: "Serge E. Hallyn" <serge@xxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: "Serge E. Hallyn" <serge@xxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Boris Lukashev <blukashev@xxxxxxxxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: "Serge E. Hallyn" <serge@xxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: "Serge E. Hallyn" <serge@xxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: Boris Lukashev <blukashev@xxxxxxxxxxxxxxxx>
• Re: Isolating abstract sockets
  • From: "Serge E. Hallyn" <serge@xxxxxxxxxx>
• sending commit notification to patch thread (was "Re: [PATCH v3 0/1] Restrict access to TIOCLINUX")
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] slub: Introduce CONFIG_SLUB_RCU_DEBUG
  • From: Andrey Konovalov <andreyknvl@xxxxxxxxx>
• Re: [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• Re: [PATCH] slub: Introduce CONFIG_SLUB_RCU_DEBUG
  • From: Marco Elver <elver@xxxxxxxxxx>
• Re: [PATCH] slub: Introduce CONFIG_SLUB_RCU_DEBUG
  • From: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
• Re: [PATCH] slub: Introduce CONFIG_SLUB_RCU_DEBUG
  • From: kernel test robot <oliver.sang@xxxxxxxxx>
• Re: [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
• Re: [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• Re: [PATCH v3 1/1] tty: Restrict access to TIOCLINUX' copy-and-paste subcommands
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 1/1] tty: Restrict access to TIOCLINUX' copy-and-paste subcommands
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
• Re: [PATCH v2 1/1] tty: Restrict access to TIOCLINUX' copy-and-paste subcommands
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• [PATCH v3 1/1] tty: Restrict access to TIOCLINUX' copy-and-paste subcommands
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• [PATCH v3 0/1] Restrict access to TIOCLINUX
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• Re: [PATCH v2 1/1] tty: Restrict access to TIOCLINUX' copy-and-paste subcommands
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] slub: Introduce CONFIG_SLUB_RCU_DEBUG
  • From: Jann Horn <jannh@xxxxxxxxxx>
• [PATCH v2 1/1] tty: Restrict access to TIOCLINUX' copy-and-paste subcommands
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• [PATCH v2 0/1] Restrict access to TIOCLINUX
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• Re: [PATCH] slub: Introduce CONFIG_SLUB_RCU_DEBUG
  • From: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
• Re: Kernel hardening project suggestion: Normalizing ->ctor slabs and TYPESAFE_BY_RCU slabs
  • From: Jann Horn <jannh@xxxxxxxxxx>
• [PATCH] slub: Introduce CONFIG_SLUB_RCU_DEBUG
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• Re: [PATCH v3 0/5] Landlock: IOCTL support - TTY restrictions RFC
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Boris Lukashev <blukashev@xxxxxxxxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: "Günther Noack" <gnoack@xxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: Serge Hallyn <serge@xxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: Kaiwan N Billimoria <kaiwan@xxxxxxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: Paul Moore <paul@xxxxxxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: Sam James <sam@xxxxxxxxxx>
• Re: [PATCH] sysctl: add config to make randomize_va_space RO
  • From: David Hildenbrand <david@xxxxxxxxxx>
• [PATCH] sysctl: add config to make randomize_va_space RO
  • From: Michael McCracken <michael.mccracken@xxxxxxxxx>
• [ANNOUNCE] [CFP] Linux Security Summit Europe (LSS-EU)
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: Per-process flag set via prctl() to deny module loading?
  • From: Tycho Andersen <tycho@tycho.pizza>
• Re: Per-process flag set via prctl() to deny module loading?
  • From: Topi Miettinen <toiwoton@xxxxxxxxx>
• Re: Per-process flag set via prctl() to deny module loading?
  • From: Topi Miettinen <toiwoton@xxxxxxxxx>
• Re: Per-process flag set via prctl() to deny module loading?
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: Per-process flag set via prctl() to deny module loading?
  • From: Tycho Andersen <tycho@tycho.pizza>
• Per-process flag set via prctl() to deny module loading?
  • From: Topi Miettinen <toiwoton@xxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Jordan Glover <Golden_Miller83@xxxxxxxxxxxxx>
• Re: [PATCH RFC] Randomized slab caches for kmalloc()
  • From: Gong Ruiqi <gongruiqi1@xxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Hanno Böck <hanno@xxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Hanno Böck <hanno@xxxxxxxxx>
• Re: [PATCH] Restrict access to TIOCLINUX
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH] Restrict access to TIOCLINUX
  • From: Hanno Böck <hanno@xxxxxxxxx>
• Re: [PATCH] mm/slab: always use cache from obj
  • From: lijiazi <jqqlijiazi@xxxxxxxxx>
• Re: [PATCH] mm/slab: always use cache from obj
  • From: lijiazi <jqqlijiazi@xxxxxxxxx>
• Re: [PATCH] mm/slab: always use cache from obj
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH] mm/slab: always use cache from obj
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Dr. David Alan Gilbert" <dgilbert@xxxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Jeremi Piotrowski <jpiotrowski@xxxxxxxxxxxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Jason Wang <jasowang@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Christophe de Dinechin <dinechin@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Christophe de Dinechin Dupont de Dinechin <cdupontd@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Christophe de Dinechin Dupont de Dinechin <cdupontd@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Christophe de Dinechin <dinechin@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: James Bottomley <jejb@xxxxxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Christophe de Dinechin <dinechin@xxxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: James Bottomley <jejb@xxxxxxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: James Bottomley <jejb@xxxxxxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Carlos Bilbao <carlos.bilbao@xxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: James Bottomley <jejb@xxxxxxxxxxxxx>
• Re: [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected
  • From: Christian Brauner <brauner@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Jörg Rödel <joro@xxxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Dr. David Alan Gilbert" <dgilbert@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Leon Romanovsky <leon@xxxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Dr. David Alan Gilbert" <dgilbert@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Leon Romanovsky <leon@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Leon Romanovsky <leon@xxxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: Leon Romanovsky <leon@xxxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: Linux guest kernel threat model for Confidential Computing
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• RE: Linux guest kernel threat model for Confidential Computing
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected
  • From: Christian Brauner <brauner@xxxxxxxxxx>
• [ANNOUNCE] Linux Security Summit North Americ (LSS-NA) CfP
  • From: James Morris <jmorris@xxxxxxxxx>
• [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Isolating abstract sockets
  • From: Stefan Bavendiek <stefan.bavendiek@xxxxxxxxxxx>
• Re: Reducing runtime complexity
  • From: Luis Chamberlain <mcgrof@xxxxxxxxxx>
• Re: Reducing runtime complexity
  • From: Stefan Bavendiek <stefan.bavendiek@xxxxxxxxxxx>
• Re: Reducing runtime complexity
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Reducing runtime complexity
  • From: Stefan Bavendiek <stefan.bavendiek@xxxxxxxxxxx>
• Re: Reducing runtime complexity
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Reducing runtime complexity
  • From: Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx>
• Reducing runtime complexity
  • From: Stefan Bavendiek <stefan.bavendiek@xxxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Solar Designer <solar@xxxxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Seth Jenkins <sethjenkins@xxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Jann Horn <jannh@xxxxxxxxxx>
• RE: [PATCH] exit: Put an upper limit on how often we can oops
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Jann Horn <jannh@xxxxxxxxxx>
• RE: [PATCH] exit: Put an upper limit on how often we can oops
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Solar Designer <solar@xxxxxxxxxxxx>
• Re: [PATCH] exit: Put an upper limit on how often we can oops
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxx>
• [PATCH] exit: Put an upper limit on how often we can oops
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [Self-introduction] - Paulo Almeida
  • From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@xxxxxxxxx>
• Re: [Self-introduction] - Paulo Almeida
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [Self-introduction] - Paulo Almeida
  • From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexey Khoroshilov <khoroshilov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexey Khoroshilov <khoroshilov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Jann Horn <jannh@xxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexey Khoroshilov <khoroshilov@xxxxxxxxx>
• Re: [PATCH] stack: Declare {randomize_,}kstack_offset to fix Sparse warnings
  • From: Gong Ruiqi <gongruiqi1@xxxxxxxxxx>
• Re: [PATCH v2] stack: Declare {randomize_,}kstack_offset to fix Sparse warnings
  • From: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
• [PATCH v2] stack: Declare {randomize_,}kstack_offset to fix Sparse warnings
  • From: "GONG, Ruiqi" <gongruiqi1@xxxxxxxxxx>
• Re: [PATCH] stack: Declare {randomize_,}kstack_offset to fix Sparse warnings
  • From: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
• [PATCH] stack: Declare {randomize_,}kstack_offset to fix Sparse warnings
  • From: "GONG, Ruiqi" <gongruiqi1@xxxxxxxxxx>
• Re: Possibility of merge of disable icotl TIOCSTI patch
  • From: Levente Polyak <levente@xxxxxxxxxxxxxxxxx>
• Re: Possibility of merge of disable icotl TIOCSTI patch
  • From: Yann Droneaud <ydroneaud@xxxxxxxxxx>
• [ANNOUNCE][CFP] Linux Security Summit Europe 2022
  • From: "Reshetova, Elena" <elena.reshetova@xxxxxxxxx>
• Re: [PATCH] Decouple slub_debug= from no_hash_pointers again
  • From: Stephen Boyd <swboyd@xxxxxxxxxxxx>
• [PATCH] Decouple slub_debug= from no_hash_pointers again
  • From: Peter Gerber <peter@xxxxxxxxxxxx>
• Re: Kernel Self Protection Project: slub_debug=ZF
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Kernel Self Protection Project: slub_debug=ZF
  • From: Peter Gerber <peter@xxxxxxxxxxxx>
• Re: OOB accesses in ax88179_rx_fixup() (in USB network card driver) - variants
  • From: Marcin Kozlowski <marcinguy@xxxxxxxxx>
• Re: Large post detailing recent Linux RNG improvements
  • From: "Jason A. Donenfeld" <Jason@xxxxxxxxx>
• Re: Large post detailing recent Linux RNG improvements
  • From: Sandy Harris <sandyinchina@xxxxxxxxx>
• Re: Large post detailing recent Linux RNG improvements
  • From: Sandy Harris <sandyinchina@xxxxxxxxx>
• OOB accesses in ax88179_rx_fixup() (in USB network card driver) - variants
  • From: Marcin Kozlowski <marcinguy@xxxxxxxxx>
• CVE Proofs of Concept
  • From: Derrick McKee <derrick.mckee@xxxxxxxxx>
• Re: [ANNOUNCE][CFP] Linux Security Summit North America 2022
  • From: James Morris <jmorris@xxxxxxxxx>
• Large post detailing recent Linux RNG improvements
  • From: "Jason A. Donenfeld" <Jason@xxxxxxxxx>
• Re: [PATCH] powerpc/32: Stop printing the virtual memory layout
  • From: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
• [ANNOUNCE][CFP] Linux Security Summit North America 2022
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: [PATCH] Add ability to disallow idmapped mounts
  • From: Christian Brauner <brauner@xxxxxxxxxx>
• Re: [PATCH] Add ability to disallow idmapped mounts
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Add ability to disallow idmapped mounts
  • From: "Anton V. Boyarshinov" <boyarsh@xxxxxxxxxxxx>
• Re: [PATCH] Add ability to disallow idmapped mounts
  • From: Christian Brauner <brauner@xxxxxxxxxx>
• Re: [PATCH] Add ability to disallow idmapped mounts
  • From: "Anton V. Boyarshinov" <boyarsh@xxxxxxxxxxxx>
• Re: [PATCH] Add ability to disallow idmapped mounts
  • From: Christian Brauner <brauner@xxxxxxxxxx>
• [PATCH] Add ability to disallow idmapped mounts
  • From: "Anton V. Boyarshinov" <boyarsh@xxxxxxxxxxxx>
• Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• Re: [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL)
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Boris Lukashev <blukashev@xxxxxxxxxxxxxxxx>
• Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [PATCH v18 4/4] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v18 3/4] arch: Wire up trusted_for(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v18 2/4] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v18 1/4] printk: Move back proc_dointvec_minmax_sysadmin() to sysctl.c
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v18 0/4] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v2] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v2] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Andrei Vagin <avagin@xxxxxxxxx>
• [PATCH v2] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] net: prestera: replace zero-length array with flexible-array member
  • From: patchwork-bot+netdevbpf@xxxxxxxxxx
• Re: [PATCH] net: prestera: replace zero-length array with flexible-array member
  • From: "Gustavo A. R. Silva" <gustavoars@xxxxxxxxxx>
• Re: [PATCH] net: prestera: replace zero-length array with flexible-array member
  • From: Volodymyr Mytnyk <volodymyr.mytnyk@xxxxxxxxxxx>
• [PATCH] net: prestera: replace zero-length array with flexible-array member
  • From: José Expósito <jose.exposito89@xxxxxxxxx>
• Re: [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxx>
• Re: [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• I'm Jordan; New Kernel Developer Here!
  • From: jordan@xxxxxxxxxxxxx
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Marco Elver <elver@xxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [ELISA Safety Architecture WG] [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [ELISA Safety Architecture WG] [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
• Re: [ELISA Safety Architecture WG] [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [ELISA Safety Architecture WG] [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [ELISA Safety Architecture WG] [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [ELISA Safety Architecture WG] [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Robert Krutsch <krutsch@xxxxxxxxx>
• Re: [ELISA Safety Architecture WG] [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Gabriele Paoloni <gpaoloni@xxxxxxxxxx>
• [PATCH v17 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v17 2/3] arch: Wire up trusted_for(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v17 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Kaiwan N Billimoria <kaiwan.billimoria@xxxxxxxxx>
• Re: [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: "Alejandro Colomar (man-pages)" <alx.manpages@xxxxxxxxx>
• Re: [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Marco Elver <elver@xxxxxxxxxx>
• Re: [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: "Alejandro Colomar (man-pages)" <alx.manpages@xxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 2/2] sysctl: introduce kernel.pkill_on_warn
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• Re: [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: "Alejandro Colomar (man-pages)" <alx.manpages@xxxxxxxxx>
• Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [fs] a0918006f9: netperf.Throughput_tps -11.6% regression
  • From: Yin Fengwei <fengwei.yin@xxxxxxxxx>
• Re: [fs] a0918006f9: netperf.Throughput_tps -11.6% regression
  • From: Yin Fengwei <fengwei.yin@xxxxxxxxx>
• [PATCH v16 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v16 2/3] arch: Wire up trusted_for(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v16 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [fs] a0918006f9: netperf.Throughput_tps -11.6% regression
  • From: Yin Fengwei <fengwei.yin@xxxxxxxxx>
• Re: [fs] a0918006f9: netperf.Throughput_tps -11.6% regression
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [fs] a0918006f9: netperf.Throughput_tps -11.6% regression
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [fs] a0918006f9: netperf.Throughput_tps -11.6% regression
  • From: kernel test robot <oliver.sang@xxxxxxxxx>
• [PATCH v2 2/2] sysctl: introduce kernel.pkill_on_warn
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• [PATCH v2 1/2] bug: do refactoring allowing to add a warning handling action
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• [PATCH v2 0/2] Introduce the pkill_on_warn parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: An analysis of current and potential security mitigations based on a TIOCSPGRP exploit
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [no subject]
  • From: jannh@xxxxxxxxxx
• [PATCH v15 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v15 2/3] arch: Wire up trusted_for(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v15 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v15 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v14 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v14 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxx>
• Re: [PATCH v14 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v14 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v14 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v14 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Florian Weimer <fw@xxxxxxxxxxxxx>
• Re: [PATCH v14 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v14 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v13 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v14 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v14 2/3] arch: Wire up trusted_for(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v14 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v14 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v13 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v13 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v13 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v13 2/3] arch: Wire up trusted_for(2)
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v13 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v12 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v12 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxx>
• Re: [PATCH v12 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v13 3/3] selftest/interpreter: Add tests for trusted_for(2) policies
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v13 2/3] arch: Wire up trusted_for(2)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v13 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• [PATCH v13 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [PATCH v12 0/3] Add trusted_for(2) (was O_MAYEXEC)
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• [PATCH] Introduce the pkill_on_warn boot parameter
  • From: Alexander Popov <alex.popov@xxxxxxxxx>
• Self introduction
  • From: Tad <tad@xxxxxxxxx>
• Re: [ANNOUNCE][CFP] Linux Security Summit 2021
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: Landlock news #1
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: [RFC PATCH v2 11/19] mm/sparsemem: Use alloc_table() for table allocations
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [RFC PATCH v2 11/19] mm/sparsemem: Use alloc_table() for table allocations
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [RFC PATCH v2 05/19] x86, mm: Use cache of page tables
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [RFC PATCH v2 10/19] x86/mm: Use alloc_table() for fill_pte(), etc
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [RFC PATCH v2 11/19] mm/sparsemem: Use alloc_table() for table allocations
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [RFC PATCH v2 17/19] x86/mm/cpa: PKS protect direct map page tables
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [RFC PATCH v2 16/19] x86/mm: Protect page tables with PKS
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [RFC PATCH v2 18/19] x86/mm: Add PKS table soft mode
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [RFC PATCH v2 17/19] x86/mm/cpa: PKS protect direct map page tables
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [RFC PATCH v2 16/19] x86/mm: Protect page tables with PKS
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [RFC PATCH v2 11/19] mm/sparsemem: Use alloc_table() for table allocations
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [RFC PATCH v2 10/19] x86/mm: Use alloc_table() for fill_pte(), etc
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [RFC PATCH v2 05/19] x86, mm: Use cache of page tables
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [RFC PATCH v2 09/19] x86/mm: Support GFP_ATOMIC in alloc_table_node()
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [RFC PATCH v2 18/19] x86/mm: Add PKS table soft mode
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• [RFC PATCH v2 19/19] x86/mm: Add PKS table debug checking
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 17/19] x86/mm/cpa: PKS protect direct map page tables
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 18/19] x86/mm: Add PKS table soft mode
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 14/19] x86/efi: Toggle table protections when copying
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 16/19] x86/mm: Protect page tables with PKS
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 15/19] x86/mm/cpa: Add set_memory_pks()
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 12/19] x86/mm: Use free_table in unmap path
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 13/19] mm/debug_vm_page_table: Use setters instead of WRITE_ONCE
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 09/19] x86/mm: Support GFP_ATOMIC in alloc_table_node()
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 00/19] PKS write protected page tables
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 05/19] x86, mm: Use cache of page tables
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 03/19] x86/mm/cpa: Add grouped page allocations
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 04/19] mm: Explicitly zero page table lock ptr
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 11/19] mm/sparsemem: Use alloc_table() for table allocations
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 07/19] x86/cpufeatures: Add feature for pks tables
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 01/19] list: Support getting most recent element in list_lru
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 02/19] list: Support list head not in object for list_lru
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 10/19] x86/mm: Use alloc_table() for fill_pte(), etc
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 06/19] x86/mm/cpa: Add perm callbacks to grouped pages
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• [RFC PATCH v2 08/19] x86/mm/cpa: Add get_grouped_page_atomic()
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• RE: [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns
  • From: "Ma, XinjianX" <xinjianx.ma@xxxxxxxxx>
• [PATCH] ucounts: Fix regression preventing increasing of rlimits in init_user_ns
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts
  • From: Alexey Gladkov <legion@xxxxxxxxxx>
• Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• RE: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts
  • From: "Ma, XinjianX" <xinjianx.ma@xxxxxxxxx>
• Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts
  • From: Alexey Gladkov <legion@xxxxxxxxxx>
• Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH v11 5/9] Reimplement RLIMIT_MSGQUEUE on top of ucounts
  • From: "Ma, XinjianX" <xinjianx.ma@xxxxxxxxx>
• Re: Leveraging pidfs for process creation without fork
  • From: John Cotton Ericson <mail@xxxxxxxxxxxxxx>
• Re: Leveraging pidfs for process creation without fork
  • From: Christian Brauner <christian.brauner@xxxxxxxxxx>
• Re: Leveraging pidfs for process creation without fork
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: Leveraging pidfs for process creation without fork
  • From: "John Ericson" <mail@xxxxxxxxxxxxxx>
• Re: Leveraging pidfs for process creation without fork
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: Leveraging pidfs for process creation without fork
  • From: "John Ericson" <list@xxxxxxxxxxxxxx>
• Re: Leveraging pidfs for process creation without fork
  • From: Christian Brauner <christian.brauner@xxxxxxxxxx>
• Leveraging pidfs for process creation without fork
  • From: John Cotton Ericson <mail@xxxxxxxxxxxxxx>
• Re: [PATCH v8 3/8] security/brute: Detect a brute force attack
  • From: Alexander Lobakin <alobakin@xxxxx>
• Re: [PATCH v8 3/8] security/brute: Detect a brute force attack
  • From: John Wood <john.wood@xxxxxxx>
• Re: [PATCH v8 3/8] security/brute: Detect a brute force attack
  • From: John Wood <john.wood@xxxxxxx>
• Re: [PATCH v8 3/8] security/brute: Detect a brute force attack
  • From: Alexander Lobakin <alobakin@xxxxx>
• Re: [PATCH v8 3/8] security/brute: Detect a brute force attack
  • From: John Wood <john.wood@xxxxxxx>
• Re: [PATCH v8 3/8] security/brute: Detect a brute force attack
  • From: Alexander Lobakin <alobakin@xxxxx>
• 回复: [PATCH 1/2] seq_buf: fix overflow when length is bigger than 8
  • From: "Zhou, Yun" <Yun.Zhou@xxxxxxxxxxxxx>
• [PATCH 2/2] seq_buf: Make trace_seq_putmem_hex() support data longer than 8
  • From: Yun Zhou <yun.zhou@xxxxxxxxxxxxx>
• [PATCH 1/2] seq_buf: fix overflow in seq_buf_putmem_hex()
  • From: Yun Zhou <yun.zhou@xxxxxxxxxxxxx>
• Re: [PATCH 1/2] seq_buf: fix overflow when length is bigger than 8
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• [PATCH 1/2] seq_buf: fix overflow when length is bigger than 8
  • From: Yun Zhou <yun.zhou@xxxxxxxxxxxxx>
• [PATCH 2/2] seq_buf: Make trace_seq_putmem_hex() support data longer than 8
  • From: Yun Zhou <yun.zhou@xxxxxxxxxxxxx>
• Re: [PATCH] seq_buf: let seq_buf_putmem_hex support len larger than 8
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• Re: [PATCH] seq_buf: let seq_buf_putmem_hex support len larger than 8
  • From: Yun Zhou <yun.zhou@xxxxxxxxxxxxx>
• Re: [PATCH] seq_buf: let seq_buf_putmem_hex support len larger than 8
  • From: Yun Zhou <yun.zhou@xxxxxxxxxxxxx>
• Re: [PATCH] seq_buf: let seq_buf_putmem_hex support len larger than 8
  • From: Yun Zhou <yun.zhou@xxxxxxxxxxxxx>
• Re: [PATCH] seq_buf: let seq_buf_putmem_hex support len larger than 8
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• Re: [PATCH] seq_buf: let seq_buf_putmem_hex support len larger than 8
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• [PATCH] seq_buf: let seq_buf_putmem_hex support len larger than 8
  • From: Yun Zhou <yun.zhou@xxxxxxxxxxxxx>
• Re: [ANNOUNCE][CFP] Linux Security Summit 2021
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: "Kurt Manucredo" <fuzzybritches0@xxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Eric Biggers <ebiggers@xxxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Eric Biggers <ebiggers@xxxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Eric Biggers <ebiggers@xxxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Eric Biggers <ebiggers@xxxxxxxxxx>
• Re: [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Edward Cree <ecree.xilinx@xxxxxxxxx>
• [PATCH v5] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Kurt Manucredo <fuzzybritches0@xxxxxxxxx>
• Re: [PATCH v8 0/8] Fork brute force attack mitigation
  • From: John Wood <john.wood@xxxxxxx>
• Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Eric Biggers <ebiggers@xxxxxxxxxx>
• Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
• Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Yonghong Song <yhs@xxxxxx>
• Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Yonghong Song <yhs@xxxxxx>
• Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
• Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v8 0/8] Fork brute force attack mitigation
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v8 0/8] Fork brute force attack mitigation
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: [PATCH v8 0/8] Fork brute force attack mitigation
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: KASAN: use-after-free Read in hci_chan_del
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: KASAN: use-after-free Read in hci_chan_del
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [syzbot] KASAN: use-after-free Read in hci_chan_del
  • From: syzbot <syzbot+305a91e025a73e4fd6ce@xxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: KASAN: use-after-free Read in hci_chan_del
  • From: SyzScope <syzscope@xxxxxxxxx>
• Re: KASAN: use-after-free Read in hci_chan_del
  • From: Greg KH <greg@xxxxxxxxx>
• Re: KASAN: use-after-free Read in hci_chan_del
  • From: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
• Re: KASAN: use-after-free Read in hci_chan_del
  • From: "Jason A. Donenfeld" <Jason@xxxxxxxxx>
• Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run
  • From: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
• [PATCH v8 8/8] MAINTAINERS: Add a new entry for the Brute LSM
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v8 7/8] Documentation: Add documentation for the Brute LSM
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v8 6/8] selftests/brute: Add tests for the Brute LSM
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v8 5/8] security/brute: Notify to userspace "task killed"
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v8 4/8] security/brute: Mitigate a brute force attack
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v8 3/8] security/brute: Detect a brute force attack
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v8 2/8] security/brute: Define a LSM and add sysctl attributes
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v8 1/8] security: Add LSM hook at the point where a task gets a fatal signal
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v8 0/8] Fork brute force attack mitigation
  • From: John Wood <john.wood@xxxxxxx>
• Re: [PATCH v11 0/9] Count rlimits in each user namespace
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [ANNOUNCE][CFP] Linux Security Summit 2021
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: [PATCH v7 0/7] Fork brute force attack mitigation
  • From: John Wood <john.wood@xxxxxxx>
• Re: [PATCH v7 0/7] Fork brute force attack mitigation
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: [PATCH v7 0/7] Fork brute force attack mitigation
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v7 7/7] MAINTAINERS: Add a new entry for the Brute LSM
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v7 6/7] Documentation: Add documentation for the Brute LSM
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v7 5/7] selftests/brute: Add tests for the Brute LSM
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v7 4/7] security/brute: Mitigate a brute force attack
  • From: John Wood <john.wood@xxxxxxx>
• Re: [PATCH v7 0/7] Fork brute force attack mitigation
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• [PATCH v7 3/7] security/brute: Detect a brute force attack
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v7 2/7] security/brute: Define a LSM and add sysctl attributes
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v7 1/7] security: Add LSM hook at the point where a task gets a fatal signal
  • From: John Wood <john.wood@xxxxxxx>
• [PATCH v7 0/7] Fork brute force attack mitigation
  • From: John Wood <john.wood@xxxxxxx>
• Re: [PATCH v11 0/9] Count rlimits in each user namespace
  • From: Alexey Gladkov <legion@xxxxxxxxxx>
• Re: [PATCH RFC 3/9] x86/mm/cpa: Add grouped page allocations
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH v11 0/9] Count rlimits in each user namespace
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 3/9] x86/mm/cpa: Add grouped page allocations
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [PATCH RFC 5/9] x86, mm: Use cache of page tables
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• New mailing list for Landlock LSM user space discussions
  • From: Mickaël Salaün <mic@xxxxxxxxxxx>
• Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression
  • From: Oliver Sang <oliver.sang@xxxxxxxxx>
• Re: [PATCH RFC 5/9] x86, mm: Use cache of page tables
  • From: Shakeel Butt <shakeelb@xxxxxxxxxx>
• Re: [PATCH RFC 5/9] x86, mm: Use cache of page tables
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• Re: [PATCH RFC 0/9] PKS write protected page tables
  • From: Ira Weiny <ira.weiny@xxxxxxxxx>
• Re: [PATCH RFC 3/9] x86/mm/cpa: Add grouped page allocations
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH RFC 5/9] x86, mm: Use cache of page tables
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH RFC 0/9] PKS write protected page tables
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH RFC 0/9] PKS write protected page tables
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH RFC 3/9] x86/mm/cpa: Add grouped page allocations
  • From: Mike Rapoport <rppt@xxxxxxxxxx>