Products Openwall GNU/*/Linux   server OS Linux Kernel Runtime Guard John the Ripper   password cracker Free & Open Source for any platform in the cloud Pro for Linux Pro for macOS Wordlists   for password cracking passwdqc   policy enforcement Free & Open Source for Unix Pro for Windows (Active Directory) yescrypt   KDF & password hashing yespower   Proof-of-Work (PoW) crypt_blowfish   password hashing phpass   ditto in PHP tcb   better password shadowing Pluggable Authentication Modules scanlogd   port scan detector popa3d   tiny POP3 daemon blists   web interface to mailing lists msulogin   single user mode login php_mt_seed   mt_rand() cracker Services Publications Articles Presentations Resources Mailing lists Community wiki Source code repositories (GitHub) Source code repositories (CVSweb) File archive & mirrors How to verify digital signatures OVE IDs What's new

kernel-hardening mailing list - 2015/11

Messages by day:

November 5 (1 message)

• Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)

• Re: Kernel Self Protection Project (Yves-Alexis Perez <corsac@...ian.org>)
• Re: Kernel Self Protection Project (Quentin Casasnovas <quentin.casasnovas@...cle.com>)
• Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)
• Re: Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)
• Re: Kernel Self Protection Project (Richard Weinberger <richard@....at>)
• Re: Kernel Self Protection Project (David Windsor <dave@...141.net>)
• Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)
• Re: Kernel Self Protection Project (Greg KH <gregkh@...uxfoundation.org>)
• Re: Kernel Self Protection Project (Mickaël Salaün <mic@...ikod.net>)
• Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)
• Proposal for kernel self protection features (Emese Revfy <re.emese@...il.com>)
• Re: Proposal for kernel self protection features (Kees Cook <keescook@...omium.org>)

• Re: Proposal for kernel self protection features (Greg KH <gregkh@...uxfoundation.org>)
• Re: Proposal for kernel self protection features (Kees Cook <keescook@...omium.org>)
• Re: Kernel Self Protection Project (Quentin Casasnovas <quentin.casasnovas@...cle.com>)
• Re: Proposal for kernel self protection features (Josh Triplett <josh@...htriplett.org>)
• Re: Proposal for kernel self protection features (Josh Triplett <josh@...htriplett.org>)
• Re: Re: Proposal for kernel self protection features (Ard Biesheuvel <ard.biesheuvel@...aro.org>)
• Re: Proposal for kernel self protection features (Emese Revfy <re.emese@...il.com>)
• Re: Proposal for kernel self protection features (Emese Revfy <re.emese@...il.com>)
• Re: Proposal for kernel self protection features (Emese Revfy <re.emese@...il.com>)
• Re: Proposal for kernel self protection features (Emese Revfy <re.emese@...il.com>)

• Re: Proposal for kernel self protection features (Kees Cook <keescook@...omium.org>)
• Re: Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)
• Re: Proposal for kernel self protection features (Josh Triplett <josh@...htriplett.org>)
• Re: Proposal for kernel self protection features (Josh Triplett <josh@...htriplett.org>)
• Re: Re: Proposal for kernel self protection features (Mathias Krause <minipli@...glemail.com>)
• Re: Re: Proposal for kernel self protection features (Alyssa Milburn <amilburn@...l.org>)
• Re: Re: Proposal for kernel self protection features (David Sterba <dave@...os.cz>)
• Re: Kernel Self Protection Project (Yves-Alexis Perez <corsac@...ian.org>)
• Re: Re: Kernel Self Protection Project (Quentin Casasnovas <quentin.casasnovas@...cle.com>)
• Re: Proposal for kernel self protection features (Emese Revfy <re.emese@...il.com>)
• Re: Proposal for kernel self protection features ("PaX Team" <pageexec@...email.hu>)
• Re: Re: Proposal for kernel self protection features ("PaX Team" <pageexec@...email.hu>)
• Re: Proposal for kernel self protection features (Greg KH <gregkh@...uxfoundation.org>)

• Re: [PATCH] video: constify geode ops structures (Dan Carpenter <dan.carpenter@...cle.com>)
• Re: [PATCH] video: constify geode ops structures (Joe Perches <joe@...ches.com>)
• Re: [PATCH] video: constify geode ops structures (Julia Lawall <julia.lawall@...6.fr>)
• Re: Kernel Self Protection Project (Rasmus Villemoes <linux@...musvillemoes.dk>)
• Re: Re: Kernel Self Protection Project (Quentin Casasnovas <quentin.casasnovas@...cle.com>)
• Re: Re: [PATCH] video: constify geode ops structures (Dan Carpenter <dan.carpenter@...cle.com>)
• Re: Re: [PATCH] video: constify geode ops structures (Dan Carpenter <dan.carpenter@...cle.com>)
• Re: Re: [PATCH] video: constify geode ops structures (Julia Lawall <julia.lawall@...6.fr>)
• Re: Re: [PATCH] video: constify geode ops structures (Dan Carpenter <dan.carpenter@...cle.com>)
• Re: Re: [PATCH] video: constify geode ops structures (Emese Revfy <re.emese@...il.com>)
• Re: Re: [PATCH] video: constify geode ops structures (Julia Lawall <julia.lawall@...6.fr>)
• Re: Re: Proposal for kernel self protection features (Laura Abbott <laura@...bott.name>)
• Re: Re: [PATCH] video: constify geode ops structures (Julia Lawall <julia.lawall@...6.fr>)
• Re: Re: [PATCH] video: constify geode ops structures (Joe Perches <joe@...ches.com>)
• Re: Re: Proposal for kernel self protection features (Jason Cooper <kernel-hardening@...edaemon.net>)
• Re: Re: Proposal for kernel self protection features (Jason Cooper <kernel-hardening@...edaemon.net>)
• Re: Re: Proposal for kernel self protection features (Valdis.Kletnieks@...edu)
• Re: Re: Proposal for kernel self protection features (Jason Cooper <kernel-hardening@...edaemon.net>)
• Re: Re: Proposal for kernel self protection features (Theodore Tso <tytso@...gle.com>)
• Re: Re: Proposal for kernel self protection features (Theodore Tso <tytso@...gle.com>)
• Re: Kernel Self Protection Project (Rasmus Villemoes <linux@...musvillemoes.dk>)
• Re: Re: Proposal for kernel self protection features (Josh Triplett <josh@...htriplett.org>)
• Re: Re: Proposal for kernel self protection features (Jason Cooper <kernel-hardening@...edaemon.net>)
• Re: Re: Proposal for kernel self protection features (Jason Cooper <kernel-hardening@...edaemon.net>)
• Re: Re: Proposal for kernel self protection features (Matthew Garrett <mjg59@...f.ucam.org>)
• Re: Re: [PATCH] video: constify geode ops structures (Kees Cook <keescook@...omium.org>)
• Re: Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)
• Re: Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)
• Re: Re: Kernel Self Protection Project (Valdis.Kletnieks@...edu)
• Re: Proposal for kernel self protection features (Kees Cook <keescook@...omium.org>)
• Re: Re: Kernel Self Protection Project (David Windsor <dave@...141.net>)
• Re: Re: [PATCH] video: constify geode ops structures (Julia Lawall <julia.lawall@...6.fr>)
• Binary blobs (HacKurx <hackurx@...il.com>)
• Re: Binary blobs (Valdis.Kletnieks@...edu)
• Re: Proposal for kernel self protection features ("PaX Team" <pageexec@...email.hu>)
• Re: Binary blobs (Kees Cook <keescook@...omium.org>)
• Re: Re: [PATCH] video: constify geode ops structures (Kees Cook <keescook@...omium.org>)
• Re: Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)
• Re: Re: Kernel Self Protection Project (Kees Cook <keescook@...omium.org>)

• Re: Re: [PATCH] video: constify geode ops structures ("PaX Team" <pageexec@...email.hu>)
• Re: Re: Kernel Self Protection Project (Quentin Casasnovas <quentin.casasnovas@...cle.com>)
• Re: Re: Proposal for kernel self protection features (Yves-Alexis Perez <corsac@...ian.org>)
• Re: Re: Proposal for kernel self protection features (Marcus Meissner <meissner@...e.de>)
• Re: Re: Proposal for kernel self protection features (Yves-Alexis Perez <corsac@...ian.org>)
• Re: [PATCH] video: constify geode ops structures (Julia Lawall <julia.lawall@...6.fr>)

• Re: Re: Proposal for kernel self protection features ("PaX Team" <pageexec@...email.hu>)
• Re: Proposal for kernel self protection features (Paolo Bonzini <pbonzini@...hat.com>)

• Re: Proposal for kernel self protection features ("PaX Team" <pageexec@...email.hu>)
• Re: Proposal for kernel self protection features (Paolo Bonzini <pbonzini@...hat.com>)

• Re: Re: Proposal for kernel self protection features (Emese Revfy <re.emese@...il.com>)
• Re: Binary blobs (HacKurx <hackurx@...il.com>)
• Re: Binary blobs (Daniel Micay <danielmicay@...il.com>)
• Re: Binary blobs (HacKurx <hackurx@...il.com>)
• Re: (west suhanic <west.suhanic@...il.com>)
• Re: (Valdis.Kletnieks@...edu)
• Re: (David Windsor <dave@...141.net>)

• Re: (Richard Weinberger <richard.weinberger@...il.com>)

• Re: (Daniel Micay <danielmicay@...il.com>)
• Re: (Daniel Micay <danielmicay@...il.com>)
• Re: (David Windsor <dave@...141.net>)
• Re: (Richard Weinberger <richard.weinberger@...il.com>)
• Re: (Daniel Micay <danielmicay@...il.com>)
• Re: (Kees Cook <keescook@...omium.org>)
• Re: (Kees Cook <keescook@...omium.org>)
• Re: (Kees Cook <keescook@...omium.org>)

• Re: (Daniel Micay <danielmicay@...il.com>)
• What ever happened to the kernel UBSan work? (Daniel Micay <danielmicay@...il.com>)
• Re: (Daniel Micay <danielmicay@...il.com>)
• Re: (Richard Weinberger <richard.weinberger@...il.com>)
• Re: (Kees Cook <keescook@...omium.org>)

• Re: GCC upstream contacts for Linux kernel bugs (Jeff Law <law@...hat.com>)

• Fwd: [Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX (Jeff Law <law@...hat.com>)
• Re: Fwd: [Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX (Kees Cook <keescook@...omium.org>)
• Re: GCC upstream contacts for Linux kernel bugs (Kees Cook <keescook@...gle.com>)

• System call interface changes (Florian Weimer <fweimer@...hat.com>)
• Re: GCC upstream contacts for Linux kernel bugs (Jeff Law <law@...hat.com>)

• Re: System call interface changes (Rich Felker <dalias@...c.org>)

• status: GRKERNSEC_KSTACKOVERFLOW (Kees Cook <keescook@...omium.org>)
• status: PAX_USERCOPY (Kees Cook <keescook@...gle.com>)
• status: GRKERNSEC_BRUTE (Kees Cook <keescook@...omium.org>)
• status: PAX_REFCOUNT (David Windsor <dave@...141.net>)
• Re: System call interface changes (Florian Weimer <fweimer@...hat.com>)
• Re: status: PAX_REFCOUNT (Kees Cook <keescook@...omium.org>)
• Re: System call interface changes (Kees Cook <keescook@...omium.org>)
• Re: System call interface changes (Rich Felker <dalias@...c.org>)
• Re: status: PAX_REFCOUNT (David Windsor <dave@...141.net>)
• Re: System call interface changes (Florian Weimer <fweimer@...hat.com>)
• Re: status: PAX_REFCOUNT (Greg KH <gregkh@...uxfoundation.org>)
• [PATCH 1/2] x86: introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• [PATCH 0/2] introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• [PATCH 2/2] x86, vdso: mark vDSO read-only after init (Kees Cook <keescook@...omium.org>)
• Re: System call interface changes (Kees Cook <keescook@...omium.org>)
• Re: status: PAX_REFCOUNT (Greg KH <gregkh@...uxfoundation.org>)
• Re: status: PAX_REFCOUNT (Kees Cook <keescook@...omium.org>)
• Re: System call interface changes (Rich Felker <dalias@...c.org>)

• Re: [PATCH 1/2] x86: introduce post-init read-only memory (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH 1/2] x86: introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• Re: Re: [PATCH 1/2] x86: introduce post-init read-only memory (Michael Ellerman <mpe@...erman.id.au>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Mathias Krause <minipli@...glemail.com>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("PaX Team" <pageexec@...email.hu>)
• Re: Re: [PATCH 1/2] x86: introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("H. Peter Anvin" <hpa@...or.com>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("H. Peter Anvin" <hpa@...or.com>)
• Re: Re: [PATCH 1/2] x86: introduce post-init read-only memory (Michael Ellerman <mpe@...erman.id.au>)
• [PATCH v2 1/4] init: create cmdline param to disable readonly (Kees Cook <keescook@...omium.org>)
• [PATCH v2 4/4] x86, vdso: mark vDSO read-only after init (Kees Cook <keescook@...omium.org>)
• [PATCH v2 3/4] lkdtm: verify that __ro_after_init works correctly (Kees Cook <keescook@...omium.org>)
• [PATCH v2 2/4] introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• [PATCH v2 0/4] introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• Re: Re: [PATCH 1/2] x86: introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• Re: status: GRKERNSEC_KSTACKOVERFLOW (Quentin Casasnovas <quentin.casasnovas@...cle.com>)

• Re: [PATCH v2 2/4] introduce post-init read-only memory ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH v2 1/4] init: create cmdline param to disable readonly ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH v2 1/4] init: create cmdline param to disable readonly (Greg KH <greg@...ah.com>)
• On techniques for preventing commit_creds() user-space abuse (Salva Peiró <speirofr@...il.com>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Clemens Ladisch <clemens@...isch.de>)
• Re: On techniques for preventing commit_creds() user-space abuse (comex <comexk@...il.com>)
• Re: [PATCH v2 1/4] init: create cmdline param to disable readonly (Ingo Molnar <mingo@...nel.org>)
• Re: On techniques for preventing commit_creds() user-space abuse (Yves-Alexis Perez <corsac@...ian.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Ingo Molnar <mingo@...nel.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Ingo Molnar <mingo@...nel.org>)
• Re: On techniques for preventing commit_creds() user-space abuse (Yann Droneaud <ydroneaud@...eya.com>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Daniel Micay <danielmicay@...il.com>)
• Re: On techniques for preventing commit_creds() user-space abuse (Salva Peiró <speirofr@...il.com>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Andy Lutomirski <luto@...capital.net>)
• Re: Re: status: GRKERNSEC_KSTACKOVERFLOW (Quentin Casasnovas <quentin.casasnovas@...cle.com>)
• Re: status: GRKERNSEC_KSTACKOVERFLOW (Quentin Casasnovas <quentin.casasnovas@...cle.com>)

• Re: [PATCH 0/2] introduce post-init read-only memory (Ingo Molnar <mingo@...nel.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Ingo Molnar <mingo@...nel.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• Re: Re: status: GRKERNSEC_KSTACKOVERFLOW (Kees Cook <keescook@...omium.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Andy Lutomirski <luto@...capital.net>)
• Re: status: GRKERNSEC_KSTACKOVERFLOW (Kees Cook <keescook@...omium.org>)
• Re: status: GRKERNSEC_KSTACKOVERFLOW (Kees Cook <keescook@...omium.org>)

• Re: status: GRKERNSEC_KSTACKOVERFLOW (Quentin Casasnovas <quentin.casasnovas@...cle.com>)
• Re: Re: status: GRKERNSEC_KSTACKOVERFLOW (Quentin Casasnovas <quentin.casasnovas@...cle.com>)
• Re: status: GRKERNSEC_KSTACKOVERFLOW (Quentin Casasnovas <quentin.casasnovas@...cle.com>)

• Re: [PATCH 0/2] introduce post-init read-only memory (Ingo Molnar <mingo@...nel.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Ingo Molnar <mingo@...nel.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Ingo Molnar <mingo@...nel.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Mathias Krause <minipli@...glemail.com>)
• user controllable usermodehelper in br_stp_if.c (Richard Weinberger <richard@....at>)
• Re: status: GRKERNSEC_BRUTE (Richard Weinberger <richard@....at>)

• Re: [PATCH 0/2] introduce post-init read-only memory (Ingo Molnar <mingo@...nel.org>)
• Re: Re: status: GRKERNSEC_KSTACKOVERFLOW (Kees Cook <keescook@...omium.org>)
• Re: user controllable usermodehelper in br_stp_if.c (Kees Cook <keescook@...omium.org>)
• Re: status: GRKERNSEC_BRUTE (Kees Cook <keescook@...omium.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("H. Peter Anvin" <hpa@...or.com>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Kees Cook <keescook@...omium.org>)
• Re: [PATCH 0/2] introduce post-init read-only memory (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH 0/2] introduce post-init read-only memory ("H. Peter Anvin" <hpa@...or.com>)
• Re: [PATCH v2 1/4] init: create cmdline param to disable readonly (Kees Cook <keescook@...omium.org>)
• [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace (ebiederm@...ssion.com (Eric W. Biederman))
• Re: [PATCH v2 2/4] introduce post-init read-only memory ("H. Peter Anvin" <hpa@...or.com>)
• Re: [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace (ebiederm@...ssion.com (Eric W. Biederman))
• Re: [PATCH v2 1/4] init: create cmdline param to disable readonly (Kees Cook <keescook@...omium.org>)
• Re: [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace (Richard Weinberger <richard@....at>)
• Re: user controllable usermodehelper in br_stp_if.c (Richard Weinberger <richard@....at>)
• [PATCH] ARM: mm: flip priority of CONFIG_DEBUG_RODATA (Kees Cook <keescook@...omium.org>)

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