kernel-hardening mailing list
Recent messages:
- 2023/05/16 #1:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (Kees Cook <keescook@...omium.org>)
- 2023/05/15 #1:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (Serge Hallyn <serge@...lyn.com>)
- 2023/05/07 #1:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (Paul Moore <paul@...l-moore.com>)
- 2023/05/06 #1:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (Kaiwan N Billimoria <kaiwan@...wantech.com>)
- 2023/05/05 #5:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (Paul Moore <paul@...l-moore.com>)
- 2023/05/05 #4:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (David Hildenbrand <david@...hat.com>)
- 2023/05/05 #3:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (David Hildenbrand <david@...hat.com>)
- 2023/05/05 #2:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (Sam James <sam@...too.org>)
- 2023/05/05 #1:
Re: [PATCH] sysctl: add config to make randomize_va_space RO (David Hildenbrand <david@...hat.com>)
- 2023/05/04 #1:
[PATCH] sysctl: add config to make randomize_va_space RO (Michael McCracken <michael.mccracken@...il.com>)
- 2023/04/17 #1:
[ANNOUNCE] [CFP] Linux Security Summit Europe (LSS-EU) ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/04/10 #6:
Re: Per-process flag set via prctl() to deny module loading? (Tycho Andersen <tycho@...ho.pizza>)
- 2023/04/10 #5:
Re: Per-process flag set via prctl() to deny module loading? (Topi Miettinen <toiwoton@...il.com>)
- 2023/04/10 #4:
Re: Per-process flag set via prctl() to deny module loading? (Topi Miettinen <toiwoton@...il.com>)
- 2023/04/10 #3:
Re: Per-process flag set via prctl() to deny module loading? (Greg KH <gregkh@...uxfoundation.org>)
- 2023/04/10 #2:
Re: Per-process flag set via prctl() to deny module loading? (Tycho Andersen <tycho@...ho.pizza>)
- 2023/04/10 #1:
Per-process flag set via prctl() to deny module loading? (Topi Miettinen <toiwoton@...il.com>)
- 2023/04/04 #1:
Re: [PATCH] Restrict access to TIOCLINUX (Jordan Glover <Golden_Miller83@...tonmail.ch>)
- 2023/04/03 #1:
Re: [PATCH RFC] Randomized slab caches for kmalloc() (Gong Ruiqi <gongruiqi1@...wei.com>)
- 2023/04/02 #6:
Re: [PATCH] Restrict access to TIOCLINUX (Greg KH <gregkh@...uxfoundation.org>)
- 2023/04/02 #5:
Re: [PATCH] Restrict access to TIOCLINUX (Hanno Böck <hanno@...eck.de>)
- 2023/04/02 #4:
Re: [PATCH] Restrict access to TIOCLINUX (Greg KH <gregkh@...uxfoundation.org>)
- 2023/04/02 #3:
Re: [PATCH] Restrict access to TIOCLINUX (Hanno Böck <hanno@...eck.de>)
- 2023/04/02 #2:
Re: [PATCH] Restrict access to TIOCLINUX (Greg KH <gregkh@...uxfoundation.org>)
- 2023/04/02 #1:
[PATCH] Restrict access to TIOCLINUX (Hanno Böck <hanno@...eck.de>)
- 2023/02/15 #3:
Re: [PATCH] mm/slab: always use cache from obj (lijiazi <jqqlijiazi@...il.com>)
- 2023/02/15 #2:
Re: [PATCH] mm/slab: always use cache from obj (lijiazi <jqqlijiazi@...il.com>)
- 2023/02/15 #1:
Re: [PATCH] mm/slab: always use cache from obj (Vlastimil Babka <vbabka@...e.cz>)
- 2023/02/14 #1:
Re: [PATCH] mm/slab: always use cache from obj (Vlastimil Babka <vbabka@...e.cz>)
- 2023/02/06 #1:
Re: Linux guest kernel threat model for Confidential Computing ("Dr. David Alan Gilbert" <dgilbert@...hat.com>)
- 2023/02/03 #1:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/02/02 #2:
Re: Linux guest kernel threat model for Confidential Computing (Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>)
- 2023/02/02 #1:
Re: Linux guest kernel threat model for Confidential Computing (Jason Wang <jasowang@...hat.com>)
- 2023/02/01 #6:
Re: Linux guest kernel threat model for Confidential Computing (Christophe de Dinechin <dinechin@...hat.com>)
- 2023/02/01 #5:
Re: Linux guest kernel threat model for Confidential Computing ("Michael S. Tsirkin" <mst@...hat.com>)
- 2023/02/01 #4:
Re: Linux guest kernel threat model for Confidential Computing (Christophe de Dinechin Dupont de Dinechin <cdupontd@...hat.com>)
- 2023/02/01 #3:
Re: Linux guest kernel threat model for Confidential Computing (Christophe de Dinechin Dupont de Dinechin <cdupontd@...hat.com>)
- 2023/02/01 #2:
Re: Linux guest kernel threat model for Confidential Computing ("Michael S. Tsirkin" <mst@...hat.com>)
- 2023/02/01 #1:
Re: Linux guest kernel threat model for Confidential Computing (Christophe de Dinechin <dinechin@...hat.com>)
- 2023/01/31 #6:
Re: Linux guest kernel threat model for Confidential Computing (James Bottomley <jejb@...ux.ibm.com>)
- 2023/01/31 #5:
Re: Linux guest kernel threat model for Confidential Computing ("Michael S. Tsirkin" <mst@...hat.com>)
- 2023/01/31 #4:
Re: Linux guest kernel threat model for Confidential Computing (Christophe de Dinechin <dinechin@...hat.com>)
- 2023/01/31 #3:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/31 #2:
Re: Linux guest kernel threat model for Confidential Computing (James Bottomley <jejb@...ux.ibm.com>)
- 2023/01/31 #1:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/30 #2:
Re: Linux guest kernel threat model for Confidential Computing (James Bottomley <jejb@...ux.ibm.com>)
- 2023/01/30 #1:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/27 #10:
Re: Linux guest kernel threat model for Confidential Computing (Carlos Bilbao <carlos.bilbao@....com>)
- 2023/01/27 #9:
Re: Linux guest kernel threat model for Confidential Computing (James Bottomley <jejb@...ux.ibm.com>)
- 2023/01/27 #8:
Re: [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are
detected (Kees Cook <keescook@...omium.org>)
- 2023/01/27 #7:
Re: Linux guest kernel threat model for Confidential Computing ("Theodore Ts'o" <tytso@....edu>)
- 2023/01/27 #6:
Re: Linux guest kernel threat model for Confidential Computing ("Michael S. Tsirkin" <mst@...hat.com>)
- 2023/01/27 #5:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/27 #4:
Re: [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are
detected (Christian Brauner <brauner@...nel.org>)
- 2023/01/27 #3:
Re: Linux guest kernel threat model for Confidential Computing ("Michael S. Tsirkin" <mst@...hat.com>)
- 2023/01/27 #2:
Re: Linux guest kernel threat model for Confidential Computing (Jörg Rödel <joro@...tes.org>)
- 2023/01/27 #1:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/26 #12:
Re: Linux guest kernel threat model for Confidential Computing ("Dr. David Alan Gilbert" <dgilbert@...hat.com>)
- 2023/01/26 #11:
Re: Linux guest kernel threat model for Confidential Computing (Leon Romanovsky <leon@...nel.org>)
- 2023/01/26 #10:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/26 #9:
Re: [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are
detected (Kees Cook <keescook@...omium.org>)
- 2023/01/26 #8:
Re: Linux guest kernel threat model for Confidential Computing ("Michael S. Tsirkin" <mst@...hat.com>)
- 2023/01/26 #7:
Re: Linux guest kernel threat model for Confidential Computing ("Dr. David Alan Gilbert" <dgilbert@...hat.com>)
- 2023/01/26 #6:
Re: Linux guest kernel threat model for Confidential Computing (Leon Romanovsky <leon@...nel.org>)
- 2023/01/26 #5:
Re: Linux guest kernel threat model for Confidential Computing (Leon Romanovsky <leon@...nel.org>)
- 2023/01/26 #4:
Re: Linux guest kernel threat model for Confidential Computing (Leon Romanovsky <leon@...nel.org>)
- 2023/01/26 #3:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/26 #2:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/26 #1:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/25 #2:
Re: Linux guest kernel threat model for Confidential Computing ("Theodore Ts'o" <tytso@....edu>)
- 2023/01/25 #1:
RE: Linux guest kernel threat model for Confidential Computing ("Reshetova, Elena" <elena.reshetova@...el.com>)
- 2023/01/24 #1:
Re: [PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are
detected (Christian Brauner <brauner@...nel.org>)
- 2023/01/20 #1:
[ANNOUNCE] Linux Security Summit North Americ (LSS-NA) CfP (James Morris <jmorris@...ei.org>)
- 2023/01/16 #1:
[PATCH] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected (Jann Horn <jannh@...gle.com>)
- 2022/12/18 #1:
Isolating abstract sockets (Stefan Bavendiek <stefan.bavendiek@...lbox.org>)
- 2022/12/06 #1:
Re: Reducing runtime complexity (Luis Chamberlain <mcgrof@...nel.org>)
- 2022/12/03 #1:
Re: Reducing runtime complexity (Stefan Bavendiek <stefan.bavendiek@...lbox.org>)
- 2022/12/02 #2:
Re: Reducing runtime complexity (Kees Cook <keescook@...omium.org>)
- 2022/12/02 #1:
Re: Reducing runtime complexity (Stefan Bavendiek <stefan.bavendiek@...lbox.org>)
- 2022/12/01 #3:
Re: Reducing runtime complexity (Kees Cook <keescook@...omium.org>)
- 2022/12/01 #2:
Re: Reducing runtime complexity (Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>)
- 2022/12/01 #1:
Reducing runtime complexity (Stefan Bavendiek <stefan.bavendiek@...lbox.org>)
- 2022/11/09 #4:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Solar Designer <solar@...nwall.com>)
- 2022/11/09 #3:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Seth Jenkins <sethjenkins@...gle.com>)
- 2022/11/09 #2:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Jann Horn <jannh@...gle.com>)
- 2022/11/09 #1:
RE: [PATCH] exit: Put an upper limit on how often we can oops (David Laight <David.Laight@...LAB.COM>)
- 2022/11/08 #5:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Kees Cook <keescook@...omium.org>)
- 2022/11/08 #4:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Kees Cook <keescook@...omium.org>)
- 2022/11/08 #3:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Kees Cook <keescook@...omium.org>)
- 2022/11/08 #2:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Jann Horn <jannh@...gle.com>)
- 2022/11/08 #1:
RE: [PATCH] exit: Put an upper limit on how often we can oops (David Laight <David.Laight@...LAB.COM>)
- 2022/11/07 #4:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Jann Horn <jannh@...gle.com>)
- 2022/11/07 #3:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Solar Designer <solar@...nwall.com>)
- 2022/11/07 #2:
Re: [PATCH] exit: Put an upper limit on how often we can oops (Linus Torvalds <torvalds@...uxfoundation.org>)
- 2022/11/07 #1:
[PATCH] exit: Put an upper limit on how often we can oops (Jann Horn <jannh@...gle.com>)
- 2022/10/11 #1:
Re: [Self-introduction] - Paulo Almeida (Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@...il.com>)
- 2022/10/10 #1:
Re: [Self-introduction] - Paulo Almeida (Kees Cook <keescook@...omium.org>)
- 2022/10/09 #1:
[Self-introduction] - Paulo Almeida (Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@...il.com>)
- 2022/07/27 #5:
Re: [PATCH] Introduce the pkill_on_warn boot parameter (Alexey Khoroshilov <khoroshilov@...ras.ru>)
- 2022/07/27 #4:
Re: [PATCH] Introduce the pkill_on_warn boot parameter (Alexey Khoroshilov <khoroshilov@...ras.ru>)
21671 messages
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.