[PATCH][RFC] CPU Jitter random number generator (resent)
Hi, [1] patch at http://www.chronox.de/jent/jitterentropy-20130516.tar.bz2 A new version of the CPU Jitter random number generator is released at http://www.chronox.de/ . The heart of the RNG is about 30 lines of easy to read code. The readme in the main directory explains the different code files. A changelog can be found on the web site. In a previous attempt (http://lkml.org/lkml/2013/2/8/476), the first iteration received comments for the lack of tests, documentation and entropy assessment. All these concerns have been addressed. The documentation of the CPU Jitter random number generator (http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html and PDF at http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and pictures are better in PDF) offers a full analysis of: - the root cause of entropy - a design of the RNG - statistical tests and analyses - entropy assessment and explanation of the flow of entropy The document also explains the core concept to have a fully decentralized entropy collector for every caller in need of entropy. Also, this RNG is well suitable for virtualized environments. Measurements on OpenVZ and KVM environments have been conducted as documented. As the Linux kernel is starved of entropy in virtualized as well as server environments, new sources of entropy are vital. The appendix of the documentation contains example use cases by providing link code to the Linux kernel crypto API, libgcrypt and OpenSSL. Links to other cryptographic libraries should be straight forward to implement. These implementations follow the concept of decentralized entropy collection. The man page provided with the source code explains the use of the API of the CPU Jitter random number generator. The test cases used to compile the documentation are available at the web site as well. Note: for the kernel crypto API, please read the provided Kconfig file for the switches and which of them are recommended in regular operation. These switches must currently be set manually in the Makefile. Ciao Stephan Signed-off-by: Stephan Mueller smuel...@chronox.de -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for May 15 (crypto /crct10dif)
On Mon, May 20, 2013 at 12:09:45PM -0700, Tim Chen wrote:
On Mon, 2013-05-20 at 19:47 +0800, Herbert Xu wrote:
Nope this is still broken. We need to move the actual crct10dif
code into crypto/. I'll fix up the patch in the tree.
Also I'm going to get rid of crc_t10dif_update_lib function. If you
still want to maintain the ordering you should do so using the
*_init constructs.
Herbert,
I used the following constructs in the pclmulqdq version of t10dif
to get the module loaded.
static const struct x86_cpu_id crct10dif_cpu_id[] = {
X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ),
{}
};
MODULE_DEVICE_TABLE(x86cpu, crct10dif_cpu_id);
However, the default generic algorithm is used
in the library function. The options CRC_T10DIF, CRYPTO_CRCT10DIF
and CRYPTO_CRCT10DIF_PCLMUL are selected as modules (which
is most likely usage scenario in distribution) on my
test machine. The library module and generic crypto module was loaded
before the pclmulqdq t10dif module during boot. How should
things be changed to get this crypto module loaded earlier before the
library? Should we add another init call level between fs and device
init calls for loading the available crypto algorithms?
The crc_t10dif_update_lib was originally used to side step this issue.
OK, the way it's meant to work is that the all versions generic
or otherwise do not call themselves by the name of the algorithm.
Instead every implementation links itself to the algorithm via
a module alias. That way the first user will cause modprobe
to load all available versions and then rank them by priority.
However, now that I've looked at it it appears that crc32c and
crct10dif have not done this properly. I'll fix that up.
Thanks,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations
The _XFER stack element size was set too small, 8 bytes, when it needs to be 16 bytes. As _XFER is the last stack element used by these implementations, the 16 byte stores with 'movdqa' corrupt the stack where the value of register %r12 is temporarily stored. As these implementations align the stack pointer to 16 bytes, this corruption did not happen every time. Patch corrects this issue. Reported-by: Julian Wollrath jwollr...@web.de Cc: Tim Chen tim.c.c...@linux.intel.com Signed-off-by: Jussi Kivilinna jussi.kivili...@iki.fi --- arch/x86/crypto/sha256-avx-asm.S |2 +- arch/x86/crypto/sha256-ssse3-asm.S |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/crypto/sha256-avx-asm.S b/arch/x86/crypto/sha256-avx-asm.S index 56610c4..642f156 100644 --- a/arch/x86/crypto/sha256-avx-asm.S +++ b/arch/x86/crypto/sha256-avx-asm.S @@ -118,7 +118,7 @@ y2 = %r15d _INP_END_SIZE = 8 _INP_SIZE = 8 -_XFER_SIZE = 8 +_XFER_SIZE = 16 _XMM_SAVE_SIZE = 0 _INP_END = 0 diff --git a/arch/x86/crypto/sha256-ssse3-asm.S b/arch/x86/crypto/sha256-ssse3-asm.S index 98d3c39..f833b74 100644 --- a/arch/x86/crypto/sha256-ssse3-asm.S +++ b/arch/x86/crypto/sha256-ssse3-asm.S @@ -111,7 +111,7 @@ y2 = %r15d _INP_END_SIZE = 8 _INP_SIZE = 8 -_XFER_SIZE = 8 +_XFER_SIZE = 16 _XMM_SAVE_SIZE = 0 _INP_END = 0 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: sha512_generic - set cra_driver_name
'sha512_generic' should set driver name now that there is alternative sha512
provider (sha512_ssse3).
Signed-off-by: Jussi Kivilinna jussi.kivili...@iki.fi
---
crypto/sha512_generic.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/sha512_generic.c b/crypto/sha512_generic.c
index 4c58620..6ed124f 100644
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
@@ -251,6 +251,7 @@ static struct shash_alg sha512_algs[2] = { {
.descsize = sizeof(struct sha512_state),
.base = {
.cra_name = sha512,
+ .cra_driver_name = sha512-generic,
.cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = SHA512_BLOCK_SIZE,
.cra_module = THIS_MODULE,
@@ -263,6 +264,7 @@ static struct shash_alg sha512_algs[2] = { {
.descsize = sizeof(struct sha512_state),
.base = {
.cra_name = sha384,
+ .cra_driver_name = sha384-generic,
.cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = SHA384_BLOCK_SIZE,
.cra_module = THIS_MODULE,
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] crypto: sha512_ssse3 - add sha384 support
Add sha384 implementation to sha512_ssse3 module.
This also fixes sha512_ssse3 module autoloading issue when 'sha384' is used
before 'sha512'. Previously in such case, just sha512_generic was loaded and
not sha512_ssse3 (since it did not provide sha384). Now if 'sha512' was used
after 'sha384' usage, sha512_ssse3 would remain unloaded. For example, this
happens with tcrypt testing module since it tests 'sha384' before 'sha512'.
Cc: Tim Chen tim.c.c...@linux.intel.com
Signed-off-by: Jussi Kivilinna jussi.kivili...@iki.fi
---
arch/x86/crypto/sha512_ssse3_glue.c | 58 ---
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/sha512_ssse3_glue.c
b/arch/x86/crypto/sha512_ssse3_glue.c
index 6cbd8df..f30cd10 100644
--- a/arch/x86/crypto/sha512_ssse3_glue.c
+++ b/arch/x86/crypto/sha512_ssse3_glue.c
@@ -194,7 +194,37 @@ static int sha512_ssse3_import(struct shash_desc *desc,
const void *in)
return 0;
}
-static struct shash_alg alg = {
+static int sha384_ssse3_init(struct shash_desc *desc)
+{
+ struct sha512_state *sctx = shash_desc_ctx(desc);
+
+ sctx-state[0] = SHA384_H0;
+ sctx-state[1] = SHA384_H1;
+ sctx-state[2] = SHA384_H2;
+ sctx-state[3] = SHA384_H3;
+ sctx-state[4] = SHA384_H4;
+ sctx-state[5] = SHA384_H5;
+ sctx-state[6] = SHA384_H6;
+ sctx-state[7] = SHA384_H7;
+
+ sctx-count[0] = sctx-count[1] = 0;
+
+ return 0;
+}
+
+static int sha384_ssse3_final(struct shash_desc *desc, u8 *hash)
+{
+ u8 D[SHA512_DIGEST_SIZE];
+
+ sha512_ssse3_final(desc, D);
+
+ memcpy(hash, D, SHA384_DIGEST_SIZE);
+ memset(D, 0, SHA512_DIGEST_SIZE);
+
+ return 0;
+}
+
+static struct shash_alg algs[] = { {
.digestsize = SHA512_DIGEST_SIZE,
.init = sha512_ssse3_init,
.update = sha512_ssse3_update,
@@ -211,7 +241,24 @@ static struct shash_alg alg = {
.cra_blocksize = SHA512_BLOCK_SIZE,
.cra_module = THIS_MODULE,
}
-};
+}, {
+ .digestsize = SHA384_DIGEST_SIZE,
+ .init = sha384_ssse3_init,
+ .update = sha512_ssse3_update,
+ .final = sha384_ssse3_final,
+ .export = sha512_ssse3_export,
+ .import = sha512_ssse3_import,
+ .descsize = sizeof(struct sha512_state),
+ .statesize = sizeof(struct sha512_state),
+ .base = {
+ .cra_name = sha384,
+ .cra_driver_name = sha384-ssse3,
+ .cra_priority = 150,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA384_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+} };
#ifdef CONFIG_AS_AVX
static bool __init avx_usable(void)
@@ -234,7 +281,7 @@ static bool __init avx_usable(void)
static int __init sha512_ssse3_mod_init(void)
{
- /* test for SSE3 first */
+ /* test for SSSE3 first */
if (cpu_has_ssse3)
sha512_transform_asm = sha512_transform_ssse3;
@@ -261,7 +308,7 @@ static int __init sha512_ssse3_mod_init(void)
else
#endif
pr_info(Using SSSE3 optimized SHA-512
implementation\n);
- return crypto_register_shash(alg);
+ return crypto_register_shashes(algs, ARRAY_SIZE(algs));
}
pr_info(Neither AVX nor SSSE3 is available/usable.\n);
@@ -270,7 +317,7 @@ static int __init sha512_ssse3_mod_init(void)
static void __exit sha512_ssse3_mod_fini(void)
{
- crypto_unregister_shash(alg);
+ crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
module_init(sha512_ssse3_mod_init);
@@ -280,3 +327,4 @@ MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(SHA512 Secure Hash Algorithm, Supplemental SSE3
accelerated);
MODULE_ALIAS(sha512);
+MODULE_ALIAS(sha384);
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] crypto: sha256_ssse3 - add sha224 support
Add sha224 implementation to sha256_ssse3 module.
This also fixes sha256_ssse3 module autoloading issue when 'sha224' is used
before 'sha256'. Previously in such case, just sha256_generic was loaded and
not sha256_ssse3 (since it did not provide sha224). Now if 'sha256' was used
after 'sha224' usage, sha256_ssse3 would remain unloaded.
Cc: Tim Chen tim.c.c...@linux.intel.com
Signed-off-by: Jussi Kivilinna jussi.kivili...@iki.fi
---
arch/x86/crypto/sha256_ssse3_glue.c | 57 ---
1 file changed, 52 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/sha256_ssse3_glue.c
b/arch/x86/crypto/sha256_ssse3_glue.c
index 597d4da..50226c4 100644
--- a/arch/x86/crypto/sha256_ssse3_glue.c
+++ b/arch/x86/crypto/sha256_ssse3_glue.c
@@ -187,7 +187,36 @@ static int sha256_ssse3_import(struct shash_desc *desc,
const void *in)
return 0;
}
-static struct shash_alg alg = {
+static int sha224_ssse3_init(struct shash_desc *desc)
+{
+ struct sha256_state *sctx = shash_desc_ctx(desc);
+
+ sctx-state[0] = SHA224_H0;
+ sctx-state[1] = SHA224_H1;
+ sctx-state[2] = SHA224_H2;
+ sctx-state[3] = SHA224_H3;
+ sctx-state[4] = SHA224_H4;
+ sctx-state[5] = SHA224_H5;
+ sctx-state[6] = SHA224_H6;
+ sctx-state[7] = SHA224_H7;
+ sctx-count = 0;
+
+ return 0;
+}
+
+static int sha224_ssse3_final(struct shash_desc *desc, u8 *hash)
+{
+ u8 D[SHA256_DIGEST_SIZE];
+
+ sha256_ssse3_final(desc, D);
+
+ memcpy(hash, D, SHA224_DIGEST_SIZE);
+ memset(D, 0, SHA256_DIGEST_SIZE);
+
+ return 0;
+}
+
+static struct shash_alg algs[] = { {
.digestsize = SHA256_DIGEST_SIZE,
.init = sha256_ssse3_init,
.update = sha256_ssse3_update,
@@ -204,7 +233,24 @@ static struct shash_alg alg = {
.cra_blocksize = SHA256_BLOCK_SIZE,
.cra_module = THIS_MODULE,
}
-};
+}, {
+ .digestsize = SHA224_DIGEST_SIZE,
+ .init = sha224_ssse3_init,
+ .update = sha256_ssse3_update,
+ .final = sha224_ssse3_final,
+ .export = sha256_ssse3_export,
+ .import = sha256_ssse3_import,
+ .descsize = sizeof(struct sha256_state),
+ .statesize = sizeof(struct sha256_state),
+ .base = {
+ .cra_name = sha224,
+ .cra_driver_name = sha224-ssse3,
+ .cra_priority = 150,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA224_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+} };
#ifdef CONFIG_AS_AVX
static bool __init avx_usable(void)
@@ -227,7 +273,7 @@ static bool __init avx_usable(void)
static int __init sha256_ssse3_mod_init(void)
{
- /* test for SSE3 first */
+ /* test for SSSE3 first */
if (cpu_has_ssse3)
sha256_transform_asm = sha256_transform_ssse3;
@@ -254,7 +300,7 @@ static int __init sha256_ssse3_mod_init(void)
else
#endif
pr_info(Using SSSE3 optimized SHA-256
implementation\n);
- return crypto_register_shash(alg);
+ return crypto_register_shashes(algs, ARRAY_SIZE(algs));
}
pr_info(Neither AVX nor SSSE3 is available/usable.\n);
@@ -263,7 +309,7 @@ static int __init sha256_ssse3_mod_init(void)
static void __exit sha256_ssse3_mod_fini(void)
{
- crypto_unregister_shash(alg);
+ crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
module_init(sha256_ssse3_mod_init);
@@ -273,3 +319,4 @@ MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(SHA256 Secure Hash Algorithm, Supplemental SSE3
accelerated);
MODULE_ALIAS(sha256);
+MODULE_ALIAS(sha384);
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] CPU Jitter random number generator (resent)
I very much like the basic notion here. The existing random(4) driver may not get enough entropy in a VM or on a device like a Linux router and I think work such as yours or HAVEGE (http://www.irisa.fr/caps/projects/hipsor/) are important research. The paper by McGuire et al of Analysis of inherent randomness of the Linux kernel (http://lwn.net/images/conf/rtlws11/random-hardware.pdf) seems to show that this is a fine source of more entropy. On the other hand, I am not certain you are doing it in the right place. My own attempt (ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/) put it in a demon that just feeds /dev/random, probably also not the right place. haveged(8) (http://www.issihosts.com/haveged/) also puts it in a demon process. It may, as you suggest, belong in the kernel instead, but I think there are arguments both ways. Could we keep random(4) mostly as is and rearrange your code to just give it more entropy? I think the large entropy pool in the existing driver is essential since we sometimes want to generate things like a 2 Kbit PGP key and it is not clear to me that your driver is entirely trustworthy under such stress. On Tue, May 21, 2013 at 2:44 AM, Stephan Mueller smuel...@chronox.de wrote: Hi, [1] patch at http://www.chronox.de/jent/jitterentropy-20130516.tar.bz2 A new version of the CPU Jitter random number generator is released at http://www.chronox.de/ . The heart of the RNG is about 30 lines of easy to read code. The readme in the main directory explains the different code files. A changelog can be found on the web site. In a previous attempt (http://lkml.org/lkml/2013/2/8/476), the first iteration received comments for the lack of tests, documentation and entropy assessment. All these concerns have been addressed. The documentation of the CPU Jitter random number generator (http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html and PDF at http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and pictures are better in PDF) offers a full analysis of: - the root cause of entropy - a design of the RNG - statistical tests and analyses - entropy assessment and explanation of the flow of entropy The document also explains the core concept to have a fully decentralized entropy collector for every caller in need of entropy. Also, this RNG is well suitable for virtualized environments. Measurements on OpenVZ and KVM environments have been conducted as documented. As the Linux kernel is starved of entropy in virtualized as well as server environments, new sources of entropy are vital. The appendix of the documentation contains example use cases by providing link code to the Linux kernel crypto API, libgcrypt and OpenSSL. Links to other cryptographic libraries should be straight forward to implement. These implementations follow the concept of decentralized entropy collection. The man page provided with the source code explains the use of the API of the CPU Jitter random number generator. The test cases used to compile the documentation are available at the web site as well. Note: for the kernel crypto API, please read the provided Kconfig file for the switches and which of them are recommended in regular operation. These switches must currently be set manually in the Makefile. Ciao Stephan Signed-off-by: Stephan Mueller smuel...@chronox.de -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Who put a stop payment on my reality check? -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] CPU Jitter random number generator (resent)
On Tue, 21 May 2013 12:09:02 -0400 Sandy Harris sandyinch...@gmail.com wrote: Hi Sandy, I very much like the basic notion here. The existing random(4) driver may not get enough entropy in a VM or on a device like a Linux router and I think work such as yours or HAVEGE ( http://www.irisa.fr/caps/projects/hipsor/) are important research. The paper by McGuire et al of Analysis of inherent randomness of the Linux kernel (http://lwn.net/images/conf/rtlws11/random-hardware.pdf) seems to show that this is a fine source of more entropy. On the other hand, I am not certain you are doing it in the right place. My own attempt (ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/) put it in a demon that just feeds /dev/random, probably also not the right place. haveged(8) ( http://www.issihosts.com/haveged/) also puts it in a demon process. It may, as you suggest, belong in the kernel instead, but I think there are arguments both ways. Thanks for your insights. What I propose is that it shall NOT have any fixed place at all. The entropy collection shall be as close to the consumer as possible. There shall be NO single one entropy collector, but one for every consumer. That is the reason, why the code I am offering has that many links to different crypto libs or even a stand-alone shared lib compilation. Also, the implementation for the kernel crypto API should be used in a way where one consumer instantiates the raw RNG or even the DRNGs independently from others. That means, in-kernel users of entropy like IPSEC shall instantiate the the kernel crypto API code independently of others. Could we keep random(4) mostly as is and rearrange your code to just give it more entropy? I think the large entropy pool in the existing driver is essential since we sometimes want to generate things like a 2 Kbit PGP key and it is not clear to me that your driver is entirely trustworthy under such stress. We can easily do that -- the different links I provide to different crypto libs can be extended by a patch to random(4) too. My goal is to go away from a central source of entropy to a fully decentralized source. Ciao Stephan -- | Cui bono? | -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] CPU Jitter random number generator (resent)
I continue to be suspicious about claims that userspace timing measurements are measuring anything other than OS behaviour. But that doesn't mean that they shouldn't exist. Personally, I believe you should try to collect as much entropy as you can, from as many places as you can. For VM's, it means we should definitely use paravirtualization to get randomness from the host OS. If you don't trust the host OS, then what on earth are you doing trying to generate a long-term public key pair on the VM in the first place? For that matter, why are you willing to expose a high value private keypair on the VM? For devices like Linux routers, what we desperately need is hardware assist; either a on-CPU hardware random number generator, or a hardware RNG from a TPM module, or having an individualized secret key generated at manufacturing time and burned onto the device. If you don't trust that the Intel hardware RNG honest, then by all means mix in additional timing information either at kernel device driver level, or from systems such as HAVEGE. What I'm against is relying only on solutions such as HAVEGE or replacing /dev/random with something scheme that only relies on CPU timing and ignores interrupt timing. Regards, - Ted -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] CPU Jitter random number generator (resent)
On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o ty...@mit.edu wrote: I continue to be suspicious about claims that userspace timing measurements are measuring anything other than OS behaviour. Yes, but they do seem to contain some entropy. See links in the original post of this thread, the havege stuff and especially the McGuire et al paper. But that doesn't mean that they shouldn't exist. Personally, I believe you should try to collect as much entropy as you can, from as many places as you can. Yes. For VM's, it means we should definitely use paravirtualization to get randomness from the host OS. Yes, I have not worked out the details but it seems clear that something along those lines would be a fine idea. For devices like Linux routers, what we desperately need is hardware assist; [or] mix in additional timing information either at kernel device driver level, or from systems such as HAVEGE. What I'm against is relying only on solutions such as HAVEGE or replacing /dev/random with something scheme that only relies on CPU timing and ignores interrupt timing. My question is how to incorporate some of that into /dev/random. At one point, timing info was used along with other stuff. Some of that got deleted later, What is the current state? Should we add more? -- Who put a stop payment on my reality check? -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
