kernel-hardening mailing list - 2017/05

Follow @Openwall on Twitter for new release announcements and other news

[<prev month] [next month>] [year] [list]

kernel-hardening mailing list - 2017/05

Mon	Tue	Wed	Thu	Fri	Sat	Sun
¹ 7	² 21	³ 13	⁴ 26	⁵ 22	⁶ 19	⁷ 5
⁸ 30	⁹ 44	¹⁰ 35	¹¹ 19	¹² 39	¹³ 2	¹⁴ 3
¹⁵ 9	¹⁶ 13	¹⁷ 2	¹⁸ 6	¹⁹ 10	²⁰ 2	²¹ 1
²² 33	²³ 22	²⁴ 21	²⁵ 9	²⁶ 31	²⁷ 11	²⁸ 20
²⁹ 17	³⁰ 33	³¹ 24

Messages by day:

May 1 (7 messages)

Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Mathias Krause <minipli@...glemail.com>)
Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)

May 2 (21 messages)

Re: It looks like there will be no more public versions of PaX and Grsec. (Rik van Riel <riel@...hat.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Olof Johansson <olof@...om.net>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Casey Schaufler <casey@...aufler-ca.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Kees Cook <keescook@...omium.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. (David Gens <david.gens@...tu-darmstadt.de>)
Re: [PATCH RFC v2 5/6] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option (Djalal Harouni <tixxdz@...il.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (bancfc@...nmailbox.org)
Re: [PATCH RFC v2 4/6] proc: support mounting private procfs instances inside same pid namespace (Djalal Harouni <tixxdz@...il.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Shawn <citypw@...il.com>)
[PATCH] ata-sff: always map page before data transfer (Tycho Andersen <tycho@...ker.com>)
Re: [PATCH RFC v2 4/6] proc: support mounting private procfs instances inside same pid namespace (Andy Lutomirski <luto@...nel.org>)
Re: Re: It looks like there will be no more public versions of PaX and Grsec. (David Gens <david.gens@...tu-darmstadt.de>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Kees Cook <keescook@...omium.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Lionel Debroux <lionel_debroux@...oo.fr>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Mathias Krause <minipli@...glemail.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Mathias Krause <minipli@...glemail.com>)
Re: Re: It looks like there will be no more public versions of PaX and Grsec. (Mathias Krause <minipli@...glemail.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Casey Schaufler <casey@...aufler-ca.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Kees Cook <keescook@...omium.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Kees Cook <keescook@...omium.org>)
Re: [PATCH] ipx: call ipxitf_put() in ioctl error path (Kees Cook <keescook@...omium.org>)

May 3 (13 messages)

Re: It looks like there will be no more public versions of PaX and Grsec. (Shawn <citypw@...il.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (David Gens <david.gens@...tu-darmstadt.de>)
Re: [PATCH RFC v2 4/6] proc: support mounting private procfs instances inside same pid namespace (Djalal Harouni <tixxdz@...il.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Rik van Riel <riel@...hat.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Rik van Riel <riel@...hat.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Rik van Riel <riel@...hat.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct (Kees Cook <keescook@...omium.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct (Greg KH <gregkh@...uxfoundation.org>)
Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct (Matt Brown <matt@...tt.com>)
Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct (Kees Cook <keescook@...omium.org>)

May 4 (26 messages)

Re: Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct ("Serge E. Hallyn" <serge@...lyn.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Kees Cook <keescook@...omium.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Lionel Debroux <lionel_debroux@...oo.fr>)
Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction (Djalal Harouni <tixxdz@...il.com>)
[PATCH] use get_random_long for the per-task stack canary (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] use get_random_long for the per-task stack canary (Arjan van de Ven <arjan@...ux.intel.com>)
Re: [PATCH] ata-sff: always map page before data transfer (Christoph Hellwig <hch@...radead.org>)
[RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [PATCH] use get_random_long for the per-task stack canary (Rik van Riel <riel@...hat.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Shawn <citypw@...il.com>)
[PATCH] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] use get_random_long for the per-task stack canary (Kees Cook <keescook@...omium.org>)
Re: [PATCH] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction ("Serge E. Hallyn" <serge@...lyn.com>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH] add the option of fortified string.h functions (Mark Rutland <mark.rutland@....com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Greg KH <gregkh@...uxfoundation.org>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Christoph Hellwig <hch@...radead.org>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Laura Abbott <labbott@...hat.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Shawn <citypw@...il.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Greg KH <gregkh@...uxfoundation.org>)
Re: [PATCH] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] add the option of fortified string.h functions (Mark Rutland <mark.rutland@....com>)
Re: [PATCH] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
[PATCH v2] ata-sff: always map page before data transfer (Tycho Andersen <tycho@...ker.com>)
Re: [PATCH] ata-sff: always map page before data transfer (Tycho Andersen <tycho@...ker.com>)

May 5 (22 messages)

Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [PATCH] add the option of fortified string.h functions (Mark Rutland <mark.rutland@....com>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Igor Stoppa <igor.stoppa@...wei.com>)
Re: [PATCH] add the option of fortified string.h functions (Mark Rutland <mark.rutland@....com>)
Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction (Djalal Harouni <tixxdz@...il.com>)
Re: [PATCH] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [PATCH v2] ata-sff: always map page before data transfer (Christoph Hellwig <hch@...radead.org>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Thomas Garnier <thgarnie@...gle.com>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Jann Horn <jannh@...gle.com>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Jann Horn <jannh@...gle.com>)
Re: [PATCH v2] ata-sff: always map page before data transfer (Tejun Heo <tj@...nel.org>)
Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction (Andy Lutomirski <luto@...nel.org>)
Re: [PATCH] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: [PATCH] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Kees Cook <keescook@...omium.org>)
auto-notify on edits to KSPP wiki page? (Clayton Craft <clayton@...ftyguy.net>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Thomas Garnier <thgarnie@...gle.com>)
[PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
[PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct (Matt Brown <matt@...tt.com>)
[PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)

May 6 (19 messages)

Re: [PATCH] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (David Gens <david.gens@...tu-darmstadt.de>)
[RFC 00/06] printk: add more new kernel pointer filter options. (Greg KH <gregkh@...uxfoundation.org>)
[RFC 1/6] lib: vsprintf: additional kernel pointer filtering options (Greg KH <gregkh@...uxfoundation.org>)
[RFC 2/6] lib: vsprintf: whitelist stack traces (Greg KH <gregkh@...uxfoundation.org>)
[RFC 3/6] lib: vsprintf: physical address kernel pointer filtering options (Greg KH <gregkh@...uxfoundation.org>)
[RFC 4/6] lib: vsprintf: default kptr_restrict to the maximum value (Greg KH <gregkh@...uxfoundation.org>)
[RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options (Greg KH <gregkh@...uxfoundation.org>)
[RFC 6/6] drivers: uio: Un-restrict sysfs pointers for UIO (Greg KH <gregkh@...uxfoundation.org>)
Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options (Joe Perches <joe@...ches.com>)
Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options (Greg KH <gregkh@...uxfoundation.org>)
Re: auto-notify on edits to KSPP wiki page? (Kees Cook <keescook@...omium.org>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [RFC 3/6] lib: vsprintf: physical address kernel pointer filtering options (Ian Campbell <ijc@...lion.org.uk>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (David Miller <davem@...emloft.net>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)

May 7 (5 messages)

Re: Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Richard Weinberger <richard.weinberger@...il.com>)
Re: Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Richard Weinberger <richard@....at>)
Re: Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: auto-notify on edits to KSPP wiki page? (James Morris <jmorris@...ei.org>)

May 8 (30 messages)

Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Mark Rutland <mark.rutland@....com>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [PATCH] add the option of fortified string.h functions (Mark Rutland <mark.rutland@....com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Greg KH <greg@...ah.com>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Mark Rutland <mark.rutland@....com>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Jann Horn <jannh@...gle.com>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Thomas Garnier <thgarnie@...gle.com>)
Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode (Daniel Gruss <daniel.gruss@...k.tugraz.at>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Laura Abbott <labbott@...hat.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: [PATCH] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] add the option of fortified string.h functions (Daniel Axtens <dja@...ens.net>)
[PATCH v3 0/2] x86/refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
[PATCH v3 1/2] x86/asm: Add suffix macro for GEN_*_RMWcc() (Kees Cook <keescook@...omium.org>)
[PATCH v3 2/2] x86/refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Thomas Garnier <thgarnie@...gle.com>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: [PATCH] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: [PATCH v3 2/2] x86/refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
Re: [PATCH v3 2/2] x86/refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)

May 9 (44 messages)

Re: [PATCH v3 2/2] x86/refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
[PATCH v2] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] add the option of fortified string.h functions (Andrew Donnellan <andrew.donnellan@....ibm.com>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Igor Stoppa <igor.stoppa@...wei.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Greg KH <greg@...ah.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Andy Lutomirski <luto@...nel.org>)
[PATCH v7 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v7 0/5] skb_to_sgvec hardening ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v7 2/5] ipsec: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v7 3/5] rxrpc: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v7 5/5] virtio_net: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v7 4/5] macsec: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
Re: [PATCH v7 0/5] skb_to_sgvec hardening ("Jason A. Donenfeld" <Jason@...c4.com>)
Re: [PATCH v7 2/5] ipsec: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
Re: [PATCH v7 5/5] virtio_net: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Thomas Garnier <thgarnie@...gle.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v7 0/5] skb_to_sgvec hardening (Johannes Berg <johannes@...solutions.net>)
Re: Re: [RFC, PATCH] x86_64: KAISER - do not mapkernel in user mode ("Fogh, Anders" <anders.fogh@...ta-adan.de>)
Re: Re: [RFC, PATCH] x86_64: KAISER - do not mapkernel in user mode (Richard Weinberger <richard@....at>)
Re: Re: [RFC, PATCH] x86_64: KAISER - do not mapkernel in user mode (Rik van Riel <riel@...hat.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Brian Gerst <brgerst@...il.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v3 2/2] x86/refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
Re: [PATCH v3 2/2] x86/refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
Re: [PATCH v3 2/2] x86/refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
[PATCH v4 1/2] x86/asm: Add suffix macro for GEN_*_RMWcc() (Kees Cook <keescook@...omium.org>)
[PATCH v4 0/2] x86/refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
[PATCH v4 2/2] x86/refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 2/2] x86/refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (David Miller <davem@...emloft.net>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Daniel Borkmann <daniel@...earbox.net>)
Re: [PATCH] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Andy Lutomirski <luto@...capital.net>)
Re: [PATCH] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)

May 10 (35 messages)

Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Andy Lutomirski <luto@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Arnd Bergmann <arnd@...db.de>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Arnd Bergmann <arnd@...db.de>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Michal Hocko <mhocko@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Igor Stoppa <igor.stoppa@...wei.com>)
Re: [PATCH] add the option of fortified string.h functions (Mark Rutland <mark.rutland@....com>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Michal Hocko <mhocko@...nel.org>)
Re: [PATCH] add the option of fortified string.h functions (Michael Ellerman <mpe@...erman.id.au>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Igor Stoppa <igor.stoppa@...wei.com>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Dave Hansen <dave.hansen@...el.com>)
[PATCH] mark most percpu globals as __ro_after_init (Daniel Micay <danielmicay@...il.com>)
[PATCH] mark protection_map as __ro_after_init (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] mark most percpu globals as __ro_after_init (Tejun Heo <tj@...nel.org>)
Re: [PATCH] mark most percpu globals as __ro_after_init (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] mark most percpu globals as __ro_after_init (Kees Cook <keescook@...omium.org>)
Re: [PATCH] mark protection_map as __ro_after_init (Kees Cook <keescook@...omium.org>)
Re: [PATCH] mark most percpu globals as __ro_after_init (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH] mark most percpu globals as __ro_after_init (Tejun Heo <tj@...nel.org>)
Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Daniel Micay <danielmicay@...il.com>)

May 11 (19 messages)

Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Andy Lutomirski <luto@...nel.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. ("PaX Team" <pageexec@...email.hu>)
Re: [PATCH v4 2/2] x86/refcount: Implement fast refcount overflow protection ("PaX Team" <pageexec@...email.hu>)
Re: [RFC 00/06] printk: add more new kernel pointer filter options. (Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Borislav Petkov <bp@...en8.de>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Kees Cook <keescook@...omium.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Daniel Micay <danielmicay@...il.com>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 2/2] x86/refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
[PATCH v8 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v8 0/5] skb_to_sgvec hardening ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v8 3/5] rxrpc: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v8 2/5] ipsec: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v8 4/5] macsec: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
[PATCH v8 5/5] virtio_net: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)
Re: [PATCH v4 2/2] x86/refcount: Implement fast refcount overflow protection (Josh Poimboeuf <jpoimboe@...hat.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Thomas Garnier <thgarnie@...gle.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Linus Torvalds <torvalds@...ux-foundation.org>)

May 12 (39 messages)

Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Andy Lutomirski <luto@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Martin Schwidefsky <schwidefsky@...ibm.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Martin Schwidefsky <schwidefsky@...ibm.com>)
Re: Re: [PATCH 01/18] gcc-plugins: Add the randstruct plugin (Loganaden Velvindron <loganaden@...il.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Ingo Molnar <mingo@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Arnd Bergmann <arnd@...db.de>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Arnd Bergmann <arnd@...db.de>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Greg KH <greg@...ah.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)
Re: It looks like there will be no more public versions of PaX and Grsec. (Hunger <hunger@...ger.hu>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Thomas Garnier <thgarnie@...gle.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Linus Torvalds <torvalds@...ux-foundation.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Russell King - ARM Linux <linux@...linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH 01/18] gcc-plugins: Add the randstruct plugin (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Russell King - ARM Linux <linux@...linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Russell King - ARM Linux <linux@...linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Rik van Riel <riel@...hat.com>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Al Viro <viro@...IV.linux.org.uk>)
Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Andy Lutomirski <luto@...nel.org>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Andy Lutomirski <luto@...nel.org>)

May 13 (2 messages)

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)

May 14 (3 messages)

[PATCH] drivers/gpu/drm: constify several *max_ioctl variables. (Lionel Debroux <lionel_debroux@...oo.fr>)
[PATCH] drivers/media: improve the return type of a bunch of .get_frontend_algo callbacks. (Lionel Debroux <lionel_debroux@...oo.fr>)
Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode (Christoph Hellwig <hch@...radead.org>)

May 15 (9 messages)

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Nicolas Belouin <nicolas@...ouin.fr>)
Re: [PATCH v8 3/5] rxrpc: check return value of skb_to_sgvec always (David Howells <dhowells@...hat.com>)
Re: [PATCH v8 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow (David Howells <dhowells@...hat.com>)
Interested in Helping KSPP (Ian Kronquist <iankronquist@...il.com>)
Re: Interested in Helping KSPP (Kees Cook <keescook@...omium.org>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Kees Cook <keescook@...omium.org>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Daniel Borkmann <daniel@...earbox.net>)
Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Peter Dolding <oiaohm@...il.com>)

May 16 (13 messages)

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Peter Dolding <oiaohm@...il.com>)
Re: [RFC 1/6] lib: vsprintf: additional kernel pointer filtering options (Petr Mladek <pmladek@...e.com>)
Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Kees Cook <keescook@...omium.org>)
Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options (Petr Mladek <pmladek@...e.com>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN ("Serge E. Hallyn" <serge@...lyn.com>)
RE: [RFC 00/06] printk: add more new kernel pointer filter options. ("Roberts, William C" <william.c.roberts@...el.com>)
Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Peter Dolding <oiaohm@...il.com>)
Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Peter Dolding <oiaohm@...il.com>)
Re: [PATCH v8 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow ("Jason A. Donenfeld" <Jason@...c4.com>)
Re: [PATCH v8 3/5] rxrpc: check return value of skb_to_sgvec always ("Jason A. Donenfeld" <Jason@...c4.com>)

May 17 (2 messages)

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Daniel Micay <danielmicay@...il.com>)

May 18 (6 messages)

Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Boris Lukashev <blukashev@...pervictus.com>)
Re: [PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Greg KH <gregkh@...uxfoundation.org>)
Re: [RFC 1/6] lib: vsprintf: additional kernel pointer filtering options (Greg KH <gregkh@...uxfoundation.org>)
Re: [RFC 5/6] lib: vsprintf: Add "%paP", "%padP" options (Greg KH <gregkh@...uxfoundation.org>)
Re: [RFC 00/06] printk: add more new kernel pointer filter options. (Greg KH <gregkh@...uxfoundation.org>)

May 19 (10 messages)

Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Peter Dolding <oiaohm@...il.com>)
Re: [PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
[RFC v3]mm: ro protection for data allocated dynamically (Igor Stoppa <igor.stoppa@...wei.com>)
[PATCH 1/1] Sealable memory support (Igor Stoppa <igor.stoppa@...wei.com>)
Re: RFC v2: post-init-read-only protection for data allocated dynamically (Igor Stoppa <igor.stoppa@...wei.com>)
[PATCH 00/31] Standardize doc formats - part 1 (Mauro Carvalho Chehab <mchehab@...pensource.com>)
[PATCH 23/31] gcc-plugins.txt: standardize document format (Mauro Carvalho Chehab <mchehab@...pensource.com>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Boris Lukashev <blukashev@...pervictus.com>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN ("Serge E. Hallyn" <serge@...lyn.com>)
RE: [RFC 00/06] printk: add more new kernel pointer filter options. ("Roberts, William C" <william.c.roberts@...el.com>)

May 20 (2 messages)

Re: [PATCH 1/1] Sealable memory support (Greg KH <gregkh@...uxfoundation.org>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)

May 21 (1 message)

[PATCH] LSM: Make security_hook_heads a local variable. (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)

May 22 (33 messages)

[PATCH 0/2] powerpc: fortify support (Daniel Axtens <dja@...ens.net>)
[PATCH 1/2] powerpc: Don't fortify prom_init (Daniel Axtens <dja@...ens.net>)
[PATCH 2/2] powerpc: Make feature-fixup tests fortify-safe (Daniel Axtens <dja@...ens.net>)
Re: [PATCH 1/2] powerpc: Don't fortify prom_init (Andrew Donnellan <andrew.donnellan@....ibm.com>)
Re: [PATCH 2/2] powerpc: Make feature-fixup tests fortify-safe (Andrew Donnellan <andrew.donnellan@....ibm.com>)
Re: [PATCH 1/2] powerpc: Don't fortify prom_init (Michael Ellerman <mpe@...erman.id.au>)
[PATCH v4 next 0/3] modules: automatic module loading restrictions (Djalal Harouni <tixxdz@...il.com>)
[PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument (Djalal Harouni <tixxdz@...il.com>)
[PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction (Djalal Harouni <tixxdz@...il.com>)
[PATCH v4 next 3/3] modules:capabilities: add a per-task modules auto-load mode (Djalal Harouni <tixxdz@...il.com>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Solar Designer <solar@...nwall.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Daniel Borkmann <daniel@...earbox.net>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Djalal Harouni <tixxdz@...il.com>)
Re: [PATCH] LSM: Make security_hook_heads a local variable. (Casey Schaufler <casey@...aufler-ca.com>)
Re: [PATCH] LSM: Make security_hook_heads a local variable. (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Solar Designer <solar@...nwall.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Kees Cook <keescook@...omium.org>)
Re: [PATCH 1/1] Sealable memory support (Igor Stoppa <igor.stoppa@...wei.com>)
Re: [PATCH] LSM: Make security_hook_heads a local variable. (Igor Stoppa <igor.stoppa@...wei.com>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Djalal Harouni <tixxdz@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Kees Cook <keescook@...omium.org>)
Re: [PATCH] LSM: Make security_hook_heads a local variable. (Casey Schaufler <casey@...aufler-ca.com>)
Re: [PATCH] LSM: Make security_hook_heads a local variable. (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Florian Fainelli <f.fainelli@...il.com>)
Re: [PATCH 1/1] Sealable memory support (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Kees Cook <keescook@...omium.org>)
[PATCH v3] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH v3] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Andy Lutomirski <luto@...nel.org>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Kees Cook <keescook@...omium.org>)

May 23 (22 messages)

Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Kees Cook <keescook@...omium.org>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Kees Cook <keescook@...omium.org>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Solar Designer <solar@...nwall.com>)
Re: [PATCH 1/1] Sealable memory support (Igor Stoppa <igor.stoppa@...wei.com>)
Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument (Djalal Harouni <tixxdz@...il.com>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Djalal Harouni <tixxdz@...il.com>)
Re: [PATCH v4 next 3/3] modules:capabilities: add a per-task modules auto-load mode (kbuild test robot <lkp@...el.com>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Kees Cook <keescook@...gle.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Shubham Bansal <illusionist.neo@...il.com>)
Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument (Kees Cook <keescook@...gle.com>)
Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit (Kees Cook <keescook@...gle.com>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Andy Lutomirski <luto@...nel.org>)
Re: [PATCH 1/1] Sealable memory support (Kees Cook <keescook@...gle.com>)
[PATCH 4.11 161/197] stackprotector: Increase the per-task stack canarys random range from 32 bits to 64 bits on 64-bit … (Greg Kroah-Hartman <gregkh@...uxfoundat…)
[PATCH 4.9 140/164] stackprotector: Increase the per-task stack canarys random range from 32 bits to 64 bits on 64-bit p… (Greg Kroah-Hartman <gregkh@...uxfoundat…)
[PATCH 4.4 094/103] stackprotector: Increase the per-task stack canarys random range from 32 bits to 64 bits on 64-bit p… (Greg Kroah-Hartman <gregkh@...uxfoundat…)
[PATCH 3.18 52/59] stackprotector: Increase the per-task stack canarys random range from 32 bits to 64 bits on 64-bit pl… (Greg Kroah-Hartman <gregkh@...uxfoundat…)
Re: [PATCH v3] add the option of fortified string.h functions (Andrew Morton <akpm@...ux-foundation.org>)

May 24 (21 messages)

Re: [PATCH v3] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument (Djalal Harouni <tixxdz@...il.com>)
[PATCH 3/5] x86: ascii armor the x86_64 boot init stack canary (riel@...hat.com)
[PATCH 4/5] arm64: ascii armor the arm64 boot init stack canary (riel@...hat.com)
[PATCH 2/5] fork,random: use get_random_canary to set tsk->stack_canary (riel@...hat.com)
[PATCH 1/5] random,stackprotect: introduce get_random_canary function (riel@...hat.com)
[PATCH v2 0/5] stackprotector: ascii armor the stack canary (riel@...hat.com)
Re: [PATCH 1/5] random,stackprotect: introduce get_random_canary function (Kees Cook <keescook@...gle.com>)
Re: [PATCH 2/5] fork,random: use get_random_canary to set tsk->stack_canary (Kees Cook <keescook@...gle.com>)
Re: [PATCH 3/5] x86: ascii armor the x86_64 boot init stack canary (Kees Cook <keescook@...gle.com>)
Re: [PATCH 4/5] arm64: ascii armor the arm64 boot init stack canary (Kees Cook <keescook@...gle.com>)
[PATCH 5/5] sh64: ascii armor the sh64 boot init stack canary (Rik van Riel <riel@...hat.com>)
Re: [PATCH 5/5] sh64: ascii armor the sh64 boot init stack canary (Kees Cook <keescook@...gle.com>)
[PATCH 5/5] sh64: ascii armor the sh64 boot init stack canary (riel@...hat.com)
Re: [PATCH 23/31] gcc-plugins.txt: standardize document format (Kees Cook <keescook@...gle.com>)
Re: [PATCH 1/1] Sealable memory support (Igor Stoppa <igor.stoppa@...wei.com>)
Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions (Djalal Harouni <tixxdz@...il.com>)
Re: [PATCH 23/31] gcc-plugins.txt: standardize document format (Mauro Carvalho Chehab <mchehab@...pensource.com>)
Patch for random mac address (HacKurx <hackurx@...il.com>)
Re: Patch for random mac address (Casey Schaufler <casey@...aufler-ca.com>)
Re: Patch for random mac address (Lukas Odzioba <lukas.odzioba@...il.com>)

May 25 (9 messages)

Re: [PATCH v3] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: Patch for random mac address (intrigeri <intrigeri@...m.org>)
Re: Patch for random mac address (Rik van Riel <riel@...hat.com>)
Re: Patch for random mac address (intrigeri <intrigeri@...m.org>)
Re: Patch for random mac address (Theodore Ts'o <tytso@....edu>)
Re: Patch for random mac address (Rik van Riel <riel@...hat.com>)
Re: Patch for random mac address (Kees Cook <keescook@...omium.org>)
Re: Patch for random mac address (Anisse Astier <anisse@...ier.eu>)
Re: [PATCH v3] add the option of fortified string.h functions (Andrew Morton <akpm@...ux-foundation.org>)

May 26 (31 messages)

Re: [PATCH v3] add the option of fortified string.h functions (Kees Cook <keescook@...omium.org>)
Re: Patch for random mac address (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH v3] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
[PATCH v4] add the option of fortified string.h functions (Daniel Micay <danielmicay@...il.com>)
Re: Patch for random mac address (HacKurx <hackurx@...il.com>)
Re: Patch for random mac address (Anisse Astier <anisse@...ier.eu>)
Re: Patch for random mac address (HacKurx <hackurx@...il.com>)
[PATCH v2 00/20] Introduce struct layout randomization plugin (Kees Cook <keescook@...omium.org>)
[PATCH v2 01/20] NFS: Avoid cross-structure casting (Kees Cook <keescook@...omium.org>)
[PATCH v2 02/20] gcc-plugins: Detail c-common.h location for GCC 4.6 (Kees Cook <keescook@...omium.org>)
[PATCH v2 03/20] compiler: Add __designated_init annotation (Kees Cook <keescook@...omium.org>)
[PATCH v2 04/20] gcc-plugins: Add the randstruct plugin (Kees Cook <keescook@...omium.org>)
[PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast (Kees Cook <keescook@...omium.org>)
[PATCH v2 06/20] randstruct: Whitelist UNIXCB cast (Kees Cook <keescook@...omium.org>)
[PATCH v2 07/20] randstruct: Whitelist big_key path struct overloading (Kees Cook <keescook@...omium.org>)
[PATCH v2 08/20] randstruct: Whitelist NIU struct page overloading (Kees Cook <keescook@...omium.org>)
[PATCH v2 09/20] randstruct: Mark various structs for randomization (Kees Cook <keescook@...omium.org>)
[PATCH v2 10/20] randstruct: opt-out externally exposed function pointer structs (Kees Cook <keescook@...omium.org>)
[PATCH v2 11/20] randstruct: Disable randomization of ACPICA structs (Kees Cook <keescook@...omium.org>)
[PATCH v2 12/20] sgi-xp: Use designated initializers (Kees Cook <keescook@...omium.org>)
[PATCH v2 13/20] drm/amdgpu: Use designated initializers (Kees Cook <keescook@...omium.org>)
[PATCH v2 14/20] drm/amd/powerplay: Use designated initializers (Kees Cook <keescook@...omium.org>)
[PATCH v2 16/20] ntfs: Use ERR_CAST() to avoid cross-structure cast (Kees Cook <keescook@...omium.org>)
[PATCH v2 17/20] ocfs2: Use ERR_CAST() to avoid cross-structure cast (Kees Cook <keescook@...omium.org>)
[PATCH v2 15/20] mtk-vcodec: Use designated initializers (Kees Cook <keescook@...omium.org>)
[PATCH v2 19/20] [RFC] task_struct: Allow randomized layout (Kees Cook <keescook@...omium.org>)
[PATCH v2 18/20] randstruct: Enable function pointer struct detection (Kees Cook <keescook@...omium.org>)
[PATCH v2 20/20] ACPICA: Use designated initializers (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 06/20] randstruct: Whitelist UNIXCB cast (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 19/20] [RFC] task_struct: Allow randomized layout (Linus Torvalds <torvalds@...ux-foundation.org>)
Re: [PATCH v2 19/20] [RFC] task_struct: Allow randomized layout (Kees Cook <keescook@...omium.org>)

May 27 (11 messages)

[PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 11/20] randstruct: Disable randomization of ACPICA structs (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 12/20] sgi-xp: Use designated initializers (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 14/20] drm/amd/powerplay: Use designated initializers (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH 0/3] ipc subsystem refcounter conversions (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 11/20] randstruct: Disable randomization of ACPICA structs (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 14/20] drm/amd/powerplay: Use designated initializers (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Casey Schaufler <casey@...aufler-ca.com>)

May 28 (20 messages)

Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast (Kees Cook <keescook@...omium.org>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Kees Cook <keescook@...omium.org>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: [PATCH v2 11/20] randstruct: Disable randomization of ACPICA structs (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 20/20] ACPICA: Use designated initializers (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 01/20] NFS: Avoid cross-structure casting (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 06/20] randstruct: Whitelist UNIXCB cast (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 07/20] randstruct: Whitelist big_key path struct overloading (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 08/20] randstruct: Whitelist NIU struct page overloading (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH v2 01/20] NFS: Avoid cross-structure casting (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 07/20] randstruct: Whitelist big_key path struct overloading (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 08/20] randstruct: Whitelist NIU struct page overloading (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2 08/20] randstruct: Whitelist NIU struct page overloading (Kees Cook <keescook@...omium.org>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Casey Schaufler <casey@...aufler-ca.com>)
Re: [PATCH 1/1] Sealable memory support (Kees Cook <keescook@...gle.com>)
Re: Re: [PATCH 1/1] Sealable memory support (Boris Lukashev <blukashev@...pervictus.com>)
[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH 1/1] Sealable memory support (Kees Cook <keescook@...gle.com>)

May 29 (17 messages)

Re: Re: [PATCH 1/1] Sealable memory support (Boris Lukashev <blukashev@...pervictus.com>)
Re: [PATCH 0/3] ipc subsystem refcounter conversions (ebiederm@...ssion.com (Eric W. Biederman))
Re: [PATCH 0/3] ipc subsystem refcounter conversions (Christoph Hellwig <hch@...radead.org>)
Re: [PATCH 0/3] ipc subsystem refcounter conversions (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Peter Dolding <oiaohm@...il.com>)
Re: [PATCH 0/3] ipc subsystem refcounter conversions (ebiederm@...ssion.com (Eric W. Biederman))
Re: [PATCH 0/3] ipc subsystem refcounter conversions (ebiederm@...ssion.com (Eric W. Biederman))
Re: [PATCH 0/3] ipc subsystem refcounter conversions (ebiederm@...ssion.com (Eric W. Biederman))
Re: [PATCH 0/3] ipc subsystem refcounter conversions (Peter Zijlstra <peterz@...radead.org>)
Re: [PATCH 0/3] ipc subsystem refcounter conversions (Peter Zijlstra <peterz@...radead.org>)
Re: [PATCH 0/3] ipc subsystem refcounter conversions (Peter Zijlstra <peterz@...radead.org>)
Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head (Casey Schaufler <casey@...aufler-ca.com>)
[PATCH v7 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
[PATCH v7 1/2] security: tty: Add owner user namespace to tty_struct (Matt Brown <matt@...tt.com>)
[PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Boris Lukashev <blukashev@...pervictus.com>)

May 30 (33 messages)

Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Casey Schaufler <casey@...aufler-ca.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Casey Schaufler <casey@...aufler-ca.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (James Morris <jmorris@...ei.org>)
Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head (James Morris <jmorris@...ei.org>)
Re: [PATCH v2 05/20] randstruct: Whitelist struct security_hook_heads cast (James Morris <jmorris@...ei.org>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Casey Schaufler <casey@...aufler-ca.com>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN ("Serge E. Hallyn" <serge@...lyn.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Daniel Micay <danielmicay@...il.com>)
Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument (Kees Cook <keescook@...gle.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Stephen Smalley <sds@...ho.nsa.gov>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Nick Kralevich <nnk@...gle.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Daniel Micay <danielmicay@...il.com>)
[PATCH v5 0/3] Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
[PATCH v5 1/3] refcount: Create unchecked atomic_t implementation (Kees Cook <keescook@...omium.org>)
[PATCH v5 2/3] x86/asm: Add suffix macro for GEN_*_RMWcc() (Kees Cook <keescook@...omium.org>)
[PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (James Morris <jmorris@...ei.org>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Daniel Micay <danielmicay@...il.com>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)

May 31 (24 messages)

Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (James Morris <jmorris@...ei.org>)
Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Matt Brown <matt@...tt.com>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
RE: [PATCH v5 1/3] refcount: Create unchecked atomic_t implementation ("Reshetova, Elena" <elena.reshetova@...el.com>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (José Bollo <jobol@...adev.net>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (James Morris <jmorris@...ei.org>)
Re: [PATCH v5 1/3] refcount: Create unchecked atomic_t implementation (Peter Zijlstra <peterz@...radead.org>)
Re: [PATCH v5 2/3] x86/asm: Add suffix macro for GEN_*_RMWcc() (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Peter Dolding <oiaohm@...il.com>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: [PATCH v5 0/3] Implement fast refcount overflow protection (Davidlohr Bueso <dave@...olabs.net>)
Re: [PATCH v5 2/3] x86/asm: Add suffix macro for GEN_*_RMWcc() (Kees Cook <keescook@...omium.org>)
Re: [PATCH v5 0/3] Implement fast refcount overflow protection (Kees Cook <keescook@...omium.org>)
Re: [PATCH 1/1] Sealable memory support (kbuild test robot <lkp@...el.com>)
Re: [PATCH v5 2/3] x86/asm: Add suffix macro for GEN_*_RMWcc() (Peter Zijlstra <peterz@...radead.org>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>)
Re: [PATCH] LSM: Convert security_hook_heads into explicit array of struct list_head (Alan Cox <gnomes@...rguk.ukuu.org.uk>)
Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN ("Serge E. Hallyn" <serge@...lyn.com>)
Re: [PATCH v5 2/3] x86/asm: Add suffix macro for GEN_*_RMWcc() (Kees Cook <keescook@...omium.org>)
Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head (Igor Stoppa <igor.stoppa@...wei.com>)
Re: [PATCH 1/1] Sealable memory support (Igor Stoppa <igor.stoppa@...wei.com>)
Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head (James Morris <jmorris@...ei.org>)

549 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.