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 - 2016/12

Messages by day:

December 1 (6 messages)

• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (David Windsor <dwindsor@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Kees Cook <keescook@...omium.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (David Windsor <dwindsor@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (David Windsor <dwindsor@...il.com>)

• [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR (Michael Ellerman <mpe@...erman.id.au>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Boqun Feng <boqun.feng@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Liljestrand Hans <ishkamiel@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Greg KH <gregkh@...uxfoundation.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (David Windsor <dwindsor@...il.com>)
• Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR (Kees Cook <keescook@...omium.org>)

• Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR (kbuild test robot <lkp@...el.com>)
• Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR (Greg KH <gregkh@...uxfoundation.org>)
• Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR (Greg KH <gregkh@...uxfoundation.org>)

• [PATCH 1/3] gcc-plugins: fix definition of DISABLE_LATENT_ENTROPY_PLUGIN (Andrew Donnellan <andrew.donnellan@....ibm.com>)
• [PATCH 2/3] powerpc: correctly disable latent entropy GCC plugin on prom_init.o (Andrew Donnellan <andrew.donnellan@....ibm.com>)
• [PATCH 3/3] powerpc: enable support for GCC plugins (Andrew Donnellan <andrew.donnellan@....ibm.com>)
• Re: [PATCH 3/3] powerpc: enable support for GCC plugins (Kees Cook <keescook@...omium.org>)
• Re: [PATCH 3/3] powerpc: enable support for GCC plugins (Emese Revfy <re.emese@...il.com>)
• Picking "Write a plugin to do format string warnings correctly" (Ruslan Kuprieiev <kupruser@...il.com>)

• Re: Re: [PATCH 3/3] powerpc: enable support for GCC plugins (Andrew Donnellan <andrew.donnellan@....ibm.com>)
• Re: [PATCH 3/3] powerpc: enable support for GCC plugins (Andrew Donnellan <andrew.donnellan@....ibm.com>)
• Re: [PATCH 3/3] powerpc: enable support for GCC plugins (Andrew Donnellan <andrew.donnellan@....ibm.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Regarding PaX (manjunatha srinivasan <manjunathan.n@...il.com>)
• Re: Picking "Write a plugin to do format string warnings correctly" (Nicolas Iooss <nicolas.iooss_linux@....org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (David Windsor <dwindsor@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (David Windsor <dwindsor@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (David Windsor <dwindsor@...il.com>)
• Re: Regarding PaX (Kees Cook <keescook@...omium.org>)
• Re: Picking "Write a plugin to do format string warnings correctly" (Kees Cook <keescook@...omium.org>)

• Re: [PATCH 3/3] powerpc: enable support for GCC plugins ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH 3/3] powerpc: enable support for GCC plugins (Kees Cook <keescook@...omium.org>)

• Re: [PATCH 3/3] powerpc: enable support for GCC plugins (Andrew Donnellan <andrew.donnellan@....ibm.com>)
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO) (AKASHI Takahiro <takahiro.akashi@...aro.org>)
• Re: [PATCH 3/3] powerpc: enable support for GCC plugins ("PaX Team" <pageexec@...email.hu>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (David Windsor <dwindsor@...il.com>)
• [PATCH] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Remaining crypto API regressions with CONFIG_VMAP_STACK (Eric Biggers <ebiggers3@...il.com>)

• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Andy Lutomirski <luto@...capital.net>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Herbert Xu <herbert@...dor.apana.org.au>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Herbert Xu <herbert@...dor.apana.org.au>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Eric Biggers <ebiggers3@...il.com>)
• Re: Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Eric Biggers <ebiggers3@...il.com>)
• Re: Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Eric Biggers <ebiggers3@...il.com>)
• Re: Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Herbert Xu <herbert@...dor.apana.org.au>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Eric Biggers <ebiggers3@...il.com>)
• Re: [PATCH] siphash: add cryptographically secure hashtable function (Greg KH <gregkh@...uxfoundation.org>)
• Re: [PATCH] siphash: add cryptographically secure hashtable function (Vegard Nossum <vegard.nossum@...il.com>)
• Re: Re: Remaining crypto API regressions with CONFIG_VMAP_STACK ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH] siphash: add cryptographically secure hashtable function ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH] siphash: add cryptographically secure hashtable function (Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>)

• Re: [PATCH] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH] siphash: add cryptographically secure hashtable function (Greg KH <gregkh@...uxfoundation.org>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Eric Biggers <ebiggers3@...il.com>)

• [PATCH v2] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2] siphash: add cryptographically secure hashtable function (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: [PATCH v2] siphash: add cryptographically secure hashtable function (Eric Biggers <ebiggers3@...il.com>)
• Re: [PATCH v2] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Andy Lutomirski <luto@...capital.net>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Gary R Hook <ghook@....com>)
• Re: [PATCH v2] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2] siphash: add cryptographically secure hashtable function (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: [PATCH v2] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v3] siphash: add cryptographically secure hashtable function (Andi Kleen <ak@...ux.intel.com>)
• Re: [PATCH v3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)

• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Herbert Xu <herbert@...dor.apana.org.au>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Herbert Xu <herbert@...dor.apana.org.au>)
• Re: [PATCH v3] siphash: add cryptographically secure hashtable function (Eric Biggers <ebiggers3@...il.com>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH v3] siphash: add cryptographically secure hashtable function (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: [PATCH v3] siphash: add cryptographically secure hashtable function (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: [PATCH v3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)

• [PATCH 1/3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH 2/3] siphash: add convenience functions for jhash converts ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH 3/3] secure_seq: use fast&secure siphash instead of slow&insecure md5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v2 2/4] siphash: add convenience functions for jhash converts ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v2 4/4] random: use siphash24 instead of md5 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Remaining crypto API regressions with CONFIG_VMAP_STACK (Herbert Xu <herbert@...dor.apana.org.au>)
• RE: [PATCH 3/3] secure_seq: use fast&secure siphash instead of slow&insecure md5 (David Laight <David.Laight@...LAB.COM>)
• RE: [PATCH 1/3] siphash: add cryptographically secure hashtable function (David Laight <David.Laight@...LAB.COM>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• RE: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform (David Laight <David.Laight@...LAB.COM>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long (Theodore Ts'o <tytso@....edu>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform (David Miller <davem@...emloft.net>)
• Re: Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v3 1/3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v3 2/3] secure_seq: use siphash24 instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• [RFC 0/4] make call_usermodehelper a bit more "safe" (Greg KH <gregkh@...uxfoundation.org>)
• [PATCH 1/4] kmod: make usermodehelper path a const string (Greg KH <gregkh@...uxfoundation.org>)
• [PATCH 2/4] drbd: rename "usermode_helper" to "drbd_usermode_helper" (Greg KH <gregkh@...uxfoundation.org>)
• [PATCH 3/4] Make static usermode helper binaries constant (Greg KH <gregkh@...uxfoundation.org>)
• [RFC 4/4] Introduce CONFIG_READONLY_USERMODEHELPER (Greg KH <gregkh@...uxfoundation.org>)
• Re: [PATCH 3/4] Make static usermode helper binaries constant (Greg KH <gregkh@...uxfoundation.org>)
• Re: Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function (Tom Herbert <tom@...bertland.com>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Mark Rutland <mark.rutland@....com>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform (Tom Herbert <tom@...bertland.com>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Kees Cook <keescook@...omium.org>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH 3/4] Make static usermode helper binaries constant (Rich Felker <dalias@...c.org>)
• Re: [RFC 4/4] Introduce CONFIG_READONLY_USERMODEHELPER (Kees Cook <keescook@...omium.org>)
• Re: [PATCH 3/4] Make static usermode helper binaries constant (Greg KH <greg@...ah.com>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [RFC 4/4] Introduce CONFIG_READONLY_USERMODEHELPER (Greg KH <gregkh@...uxfoundation.org>)
• Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function (kbuild test robot <lkp@...el.com>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function (Tom Herbert <tom@...bertland.com>)
• Re: [PATCH v3 2/3] secure_seq: use siphash24 instead of md5_transform (kbuild test robot <lkp@...el.com>)
• Re: [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long (kbuild test robot <lkp@...el.com>)
• Re: [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long (kbuild test robot <lkp@...el.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function (Tom Herbert <tom@...bertland.com>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Greg Kroah-Hartman <gregkh@...uxfoundation.org>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)

• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v4 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v4 2/4] siphash: add N[qd]word helpers ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v4 3/4] secure_seq: use siphash instead of md5_transform ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v4 4/4] random: use siphash instead of MD5 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v4 1/4] siphash: add cryptographically secure hashtable function (kbuild test robot <lkp@...el.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Herbert Xu <herbert@...dor.apana.org.au>)
• Re: Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Daniel Micay <danielmicay@...il.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• RE: [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long (David Laight <David.Laight@...LAB.COM>)
• RE: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function (David Laight <David.Laight@...LAB.COM>)
• RE: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (David Laight <David.Laight@...LAB.COM>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• RE: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (David Laight <David.Laight@...LAB.COM>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• RE: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (David Laight <David.Laight@...LAB.COM>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• RE: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (David Laight <David.Laight@...LAB.COM>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses"" (Thomas Garnier <thgarnie@...gle.com>)
• Re: [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses"" (ebiederm@...ssion.com (Eric W. Biederman))
• Re: [PATCH 3/4] Make static usermode helper binaries constant (Greg KH <greg@...ah.com>)
• Re: [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses"" (Thomas Garnier <thgarnie@...gle.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses"" (Thomas Garnier <thgarnie@...gle.com>)
• [PATCH v5 0/4] The SipHash Patchset ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v5 2/4] siphash: add Nu{32,64} helpers ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v5 3/4] secure_seq: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v5 4/4] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH 3/4] Make static usermode helper binaries constant (Daniel Micay <danielmicay@...il.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Peter Zijlstra <peterz@...radead.org>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Peter Zijlstra <peterz@...radead.org>)
• Re: Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH 3/4] Make static usermode helper binaries constant (Greg KH <gregkh@...uxfoundation.org>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function ("Jason A. Donenfeld" <Jason@...c4.com>)

• Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH 3/4] Make static usermode helper binaries constant (Daniel Micay <danielmicay@...il.com>)
• Re: [PATCH 3/4] Make static usermode helper binaries constant (Daniel Micay <danielmicay@...il.com>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (NeilBrown <neilb@...e.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (kbuild test robot <lkp@...el.com>)
• [PATCH v6 0/5] The SipHash Patchset ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v6 1/5] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v6 2/5] secure_seq: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v6 3/5] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v6 4/5] md5: remove from lib and only live in crypto ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v6 5/5] syncookies: use SipHash in place of SHA1 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses"" (Baoquan He <bhe@...hat.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>)
• [PATCH] gcc-plugin: include memmodel.h and tree_vrp.h for gcc-7 (Arnd Bergmann <arnd@...db.de>)
• RE: [PATCH v5 3/4] secure_seq: use SipHash in place of MD5 (David Laight <David.Laight@...LAB.COM>)
• RE: [PATCH v5 2/4] siphash: add Nu{32,64} helpers (David Laight <David.Laight@...LAB.COM>)
• RE: Conversion from atomic_t to refcount_t: summary of issues ("Reshetova, Elena" <elena.reshetova@...el.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Greg KH <gregkh@...uxfoundation.org>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: [PATCH] gcc-plugin: include memmodel.h and tree_vrp.h for gcc-7 (Emese Revfy <re.emese@...il.com>)
• RE: [PATCH v5 2/4] siphash: add Nu{32,64} helpers ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v5 3/4] secure_seq: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF (David Laight <David.Laight@...LAB.COM>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Working on lib/test_bpf.c tests for eBPF constant blinding ("Sandra Escandor-O'Keefe" <rvonflugel@...il.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Working on lib/test_bpf.c tests for eBPF constant blinding (Kees Cook <keescook@...omium.org>)
• Re: [PATCH] gcc-plugin: include memmodel.h and tree_vrp.h for gcc-7 (Kees Cook <keescook@...omium.org>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Tom Herbert <tom@...bertland.com>)
• Re: Working on lib/test_bpf.c tests for eBPF constant blinding (Sandra Escandor-O'Keefe <rvonflugel@...il.com>)
• Re: Working on lib/test_bpf.c tests for eBPF constant blinding (Kees Cook <keescook@...omium.org>)
• Re: Working on lib/test_bpf.c tests for eBPF constant blinding (Daniel Borkmann <daniel@...earbox.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Theodore Ts'o <tytso@....edu>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Daniel Micay <danielmicay@...il.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH] gcc-plugins: update gcc-common.h for gcc-7 (Kees Cook <keescook@...omium.org>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Tom Herbert <tom@...bertland.com>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH] latent_entropy: fix ARM build error on earlier gcc (Kees Cook <keescook@...omium.org>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v6 3/5] random: use SipHash in place of MD5 (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH v6 3/5] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v4 2/4] util: Move type casts into is_kernel_rodata (Kees Cook <keescook@...omium.org>)
• [PATCH v4 4/4] initify: Mark functions with the __unverified_nocapture attribute (Kees Cook <keescook@...omium.org>)
• [PATCH v4 0/4] Introduce the initify gcc plugin (Kees Cook <keescook@...omium.org>)
• [PATCH v4 3/4] initify: Mark functions with the __nocapture attribute (Kees Cook <keescook@...omium.org>)
• [PATCH v4 1/4] gcc-plugins: Add the initify gcc plugin (Kees Cook <keescook@...omium.org>)
• Re: [PATCH v6 3/5] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v6 3/5] random: use SipHash in place of MD5 (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH] latent_entropy: fix ARM build error on earlier gcc ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v4 0/4] Introduce the initify gcc plugin (Kees Cook <keescook@...omium.org>)
• Re: [PATCH] latent_entropy: fix ARM build error on earlier gcc (Kees Cook <keescook@...omium.org>)
• Re: [PATCH v6 3/5] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v4 1/4] gcc-plugins: Add the initify gcc plugin ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH v4 1/4] gcc-plugins: Add the initify gcc plugin (Kees Cook <keescook@...omium.org>)
• Re: [PATCH v4 1/4] gcc-plugins: Add the initify gcc plugin ("PaX Team" <pageexec@...email.hu>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)

• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Jeffrey Walton <noloader@...il.com>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Theodore Ts'o <tytso@....edu>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Jeffrey Walton <noloader@...il.com>)

• Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function (Christian Kujau <lists@...dbynature.de>)

• RE: Conversion from atomic_t to refcount_t: summary of issues ("Reshetova, Elena" <elena.reshetova@...el.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: [PATCH v4 0/4] Introduce the initify gcc plugin (Emese Revfy <re.emese@...il.com>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Jiri Kosina <jikos@...nel.org>)
• RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF (David Laight <David.Laight@...LAB.COM>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>)
• Re: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)
• RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v4 0/4] Introduce the initify gcc plugin (Laura Abbott <labbott@...hat.com>)
• Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF (Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>)
• Re: HalfSipHash Acceptable Usage (Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>)
• Re: HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)

• RE: Conversion from atomic_t to refcount_t: summary of issues ("Reshetova, Elena" <elena.reshetova@...el.com>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Greg KH <gregkh@...uxfoundation.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Greg KH <gregkh@...uxfoundation.org>)
• RE: Conversion from atomic_t to refcount_t: summary of issues ("Reshetova, Elena" <elena.reshetova@...el.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Greg KH <gregkh@...uxfoundation.org>)
• RE: Conversion from atomic_t to refcount_t: summary of issues ("Reshetova, Elena" <elena.reshetova@...el.com>)
• RE: Conversion from atomic_t to refcount_t: summary of issues ("Reshetova, Elena" <elena.reshetova@...el.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Greg KH <gregkh@...uxfoundation.org>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Jiri Kosina <jikos@...nel.org>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Jiri Kosina <jikos@...nel.org>)
• Re: [RFC 0/4] make call_usermodehelper a bit more "safe" (Greg KH <gregkh@...uxfoundation.org>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Liljestrand Hans <ishkamiel@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• RE: Re: Conversion from atomic_t to refcount_t: summary of issues ("Reshetova, Elena" <elena.reshetova@...el.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Liljestrand Hans <ishkamiel@...il.com>)
• Re: Conversion from atomic_t to refcount_t: summary of issues (Peter Zijlstra <peterz@...radead.org>)
• Re: HalfSipHash Acceptable Usage (Theodore Ts'o <tytso@....edu>)
• Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: HalfSipHash Acceptable Usage (Eric Dumazet <eric.dumazet@...il.com>)

• Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: HalfSipHash Acceptable Usage (Eric Dumazet <eric.dumazet@...il.com>)
• Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: HalfSipHash Acceptable Usage (Eric Dumazet <eric.dumazet@...il.com>)
• Re: HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: HalfSipHash Acceptable Usage (Rik van Riel <riel@...hat.com>)
• Re: Re: HalfSipHash Acceptable Usage (Rik van Riel <riel@...hat.com>)
• Re: Re: HalfSipHash Acceptable Usage (Eric Dumazet <eric.dumazet@...il.com>)
• Re: HalfSipHash Acceptable Usage (Linus Torvalds <torvalds@...ux-foundation.org>)
• Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: HalfSipHash Acceptable Usage (Theodore Ts'o <tytso@....edu>)
• Re: Re: HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v7 0/6] The SipHash Patchset ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v7 1/6] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v7 2/6] secure_seq: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v7 4/6] md5: remove from lib and only live in crypto ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v7 5/6] syncookies: use SipHash in place of SHA1 ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH v7 6/6] siphash: implement HalfSipHash1-3 for hash tables ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Andy Lutomirski <luto@...capital.net>)

• Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v7 6/6] siphash: implement HalfSipHash1-3 for hash tables (Andi Kleen <ak@...ux.intel.com>)
• Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: [PATCH v7 1/6] siphash: add cryptographically secure PRF (Stephen Hemminger <stephen@...workplumber.org>)
• Re: [PATCH v7 1/6] siphash: add cryptographically secure PRF ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: HalfSipHash Acceptable Usage (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Andy Lutomirski <luto@...nel.org>)
• Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Andy Lutomirski <luto@...capital.net>)
• Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: HalfSipHash Acceptable Usage ("George Spelvin" <linux@...encehorizons.net>)
• Re: Re: HalfSipHash Acceptable Usage ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Theodore Ts'o <tytso@....edu>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Andy Lutomirski <luto@...capital.net>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Theodore Ts'o <tytso@....edu>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Theodore Ts'o <tytso@....edu>)
• BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Andy Lutomirski <luto@...capital.net>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Andy Lutomirski <luto@...capital.net>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Theodore Ts'o <tytso@....edu>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Andy Lutomirski <luto@...capital.net>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Andy Lutomirski <luto@...capital.net>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• [PATCH 1/2] random: use chacha20 for get_random_int/long ("Jason A. Donenfeld" <Jason@...c4.com>)
• [PATCH 2/2] random: convert get_random_int/long into get_random_u32/u64 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Andy Lutomirski <luto@...nel.org>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Alexei Starovoitov <alexei.starovoitov@...il.com>)
• Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5 (Theodore Ts'o <tytso@....edu>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Andy Lutomirski <luto@...nel.org>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Hannes Frederic Sowa <hannes@...essinduktion.org>)

• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Daniel Borkmann <daniel@...earbox.net>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Daniel Borkmann <daniel@...earbox.net>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Daniel Borkmann <daniel@...earbox.net>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Andy Lutomirski <luto@...capital.net>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Andy Lutomirski <luto@...capital.net>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: BPF hash algo (Re: Re: [PATCH v7 3/6] random: use SipHash in place of MD5) ("Jason A. Donenfeld" <Jason@...c4.com>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)

• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)

• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) (Hannes Frederic Sowa <hannes@...essinduktion.org>)
• Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) ("George Spelvin" <linux@...encehorizons.net>)

• [RFC PATCH 00/19] refcount_t API + usage (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 03/19] For some obscure reason apparmor thinks its needs to locally implement kref primitives that already ex… (Elena Reshetova <elena.reshetova@...el.…)
• [RFC PATCH 01/19] Since we need to change the implementation, stop exposing internals. Provide kref_read() to read the c… (Elena Reshetova <elena.reshetova@...el.…)
• [RFC PATCH 02/19] By general sentiment kref_sub() is a bad interface, make it go away. (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 04/19] Because home-rolling your own is _awesome_, stop doing it. Provide kref_put_lock(), just like kref_put… (Elena Reshetova <elena.reshetova@...el.…)
• [RFC PATCH 05/19] Leak references by unbalanced get, instead of poking at kref implementation details. (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 06/19] Provide refcount_t, an atomic_t like primitive built just for refcounting. (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 07/19] mixed: kref fixes (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 08/19] kernel, mm: convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 09/19] net: convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 10/19] fs: convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 11/19] security: convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 12/19] sound: convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 13/19] ipc: covert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 14/19] tools: convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 15/19] block: convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 16/19] drivers: net convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 18/19] drivers: infiniband convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• [RFC PATCH 17/19] drivers: misc convert from atomic_t to refcount_t (Elena Reshetova <elena.reshetova@...el.com>)
• Security issues on ARM processor (amitsagar gowda <amitsagargowda@...il.com>)
• Re: [RFC PATCH 01/19] Since we need to change the implementation, stop exposing internals. Provide kref_read() to read the… (Greg KH <gregkh@...uxfoundation.org>)
• RE: Re: [RFC PATCH 01/19] Since we need to change the implementation, stop exposing internals. Provide kref_read() to … ("Reshetova, Elena" <elena.reshetova@int…)

• Re: [RFC PATCH 06/19] Provide refcount_t, an atomic_t like primitive built just for refcounting. (Eric Biggers <ebiggers3@...il.com>)
• Re: Re: [RFC PATCH 01/19] Since we need to change the implementation, stop exposing internals. Provide kref_read() to read… (Greg KH <gregkh@...uxfoundation.org>)
• RE: Re: [RFC PATCH 01/19] Since we need to change the implementation, stop exposing internals. Provide kref_read() to … ("Reshetova, Elena" <elena.reshetova@int…)
• RE: [RFC PATCH 06/19] Provide refcount_t, an atomic_t like primitive built just for refcounting. ("Reshetova, Elena" <elena.reshetova@...el.com>)
• Re: [RFC PATCH 06/19] Provide refcount_t, an atomic_t like primitive built just for refcounting. (Eric Biggers <ebiggers3@...il.com>)

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