Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-12 Thread Paolo Bonzini 


On 12/11/2015 15:08, Jan Kiszka wrote:
> On 2015-11-11 14:12, Austin S Hemmelgarn wrote:
>> On 2015-11-11 08:07, Paolo Bonzini wrote:
>>>
>>>
>>> On 11/11/2015 13:47, Austin S Hemmelgarn wrote:
>
 I just finished running a couple of tests in a KVM instance running
 nested on a Xen HVM instance, and found no issues, so for the set as a
 whole:

 Tested-by: Austin S. Hemmelgarn 

 Now to hope the equivalent fix for Xen gets into the Gentoo repositories
 soon, as the issue propagates down through nested virtualization and
 ties up the CPU regardless (and in turn triggers the watchdog).
>>>
>>> Note that nested guests should _not_ lock up the outer (L0) hypervisor
>>> if the outer hypervisor has the fix.  At least this is the case for KVM:
>>> a fixed outer KVM can protect any vulnerable nested (L1) hypervisor from
>>> malicious nested guests.  A vulnerable outer KVM is also protected if
>>> the nested hypervisor has the workaround.
>>>
>> I already knew this, I just hadn't remembered that I hadn't updated Xen
>> since before the XSA and patch for this had been posted (and it took me
>> a while to remember this when I accidentally panicked Xen :))
> 
> As I'm lazy, both to search and to write something myself: is there
> already a test case for the issue(s) circling around?

To everybody: keep reproducers offlist, please.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-12 Thread Jan Kiszka 
On 2015-11-11 14:12, Austin S Hemmelgarn wrote:
> On 2015-11-11 08:07, Paolo Bonzini wrote:
>>
>>
>> On 11/11/2015 13:47, Austin S Hemmelgarn wrote:

>>> I just finished running a couple of tests in a KVM instance running
>>> nested on a Xen HVM instance, and found no issues, so for the set as a
>>> whole:
>>>
>>> Tested-by: Austin S. Hemmelgarn 
>>>
>>> Now to hope the equivalent fix for Xen gets into the Gentoo repositories
>>> soon, as the issue propagates down through nested virtualization and
>>> ties up the CPU regardless (and in turn triggers the watchdog).
>>
>> Note that nested guests should _not_ lock up the outer (L0) hypervisor
>> if the outer hypervisor has the fix.  At least this is the case for KVM:
>> a fixed outer KVM can protect any vulnerable nested (L1) hypervisor from
>> malicious nested guests.  A vulnerable outer KVM is also protected if
>> the nested hypervisor has the workaround.
>>
> I already knew this, I just hadn't remembered that I hadn't updated Xen
> since before the XSA and patch for this had been posted (and it took me
> a while to remember this when I accidentally panicked Xen :))
> 

As I'm lazy, both to search and to write something myself: is there
already a test case for the issue(s) circling around?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-12 Thread Jan Kiszka 
On 2015-11-11 14:12, Austin S Hemmelgarn wrote:
> On 2015-11-11 08:07, Paolo Bonzini wrote:
>>
>>
>> On 11/11/2015 13:47, Austin S Hemmelgarn wrote:

>>> I just finished running a couple of tests in a KVM instance running
>>> nested on a Xen HVM instance, and found no issues, so for the set as a
>>> whole:
>>>
>>> Tested-by: Austin S. Hemmelgarn 
>>>
>>> Now to hope the equivalent fix for Xen gets into the Gentoo repositories
>>> soon, as the issue propagates down through nested virtualization and
>>> ties up the CPU regardless (and in turn triggers the watchdog).
>>
>> Note that nested guests should _not_ lock up the outer (L0) hypervisor
>> if the outer hypervisor has the fix.  At least this is the case for KVM:
>> a fixed outer KVM can protect any vulnerable nested (L1) hypervisor from
>> malicious nested guests.  A vulnerable outer KVM is also protected if
>> the nested hypervisor has the workaround.
>>
> I already knew this, I just hadn't remembered that I hadn't updated Xen
> since before the XSA and patch for this had been posted (and it took me
> a while to remember this when I accidentally panicked Xen :))
> 

As I'm lazy, both to search and to write something myself: is there
already a test case for the issue(s) circling around?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-12 Thread Paolo Bonzini 


On 12/11/2015 15:08, Jan Kiszka wrote:
> On 2015-11-11 14:12, Austin S Hemmelgarn wrote:
>> On 2015-11-11 08:07, Paolo Bonzini wrote:
>>>
>>>
>>> On 11/11/2015 13:47, Austin S Hemmelgarn wrote:
>
 I just finished running a couple of tests in a KVM instance running
 nested on a Xen HVM instance, and found no issues, so for the set as a
 whole:

 Tested-by: Austin S. Hemmelgarn 

 Now to hope the equivalent fix for Xen gets into the Gentoo repositories
 soon, as the issue propagates down through nested virtualization and
 ties up the CPU regardless (and in turn triggers the watchdog).
>>>
>>> Note that nested guests should _not_ lock up the outer (L0) hypervisor
>>> if the outer hypervisor has the fix.  At least this is the case for KVM:
>>> a fixed outer KVM can protect any vulnerable nested (L1) hypervisor from
>>> malicious nested guests.  A vulnerable outer KVM is also protected if
>>> the nested hypervisor has the workaround.
>>>
>> I already knew this, I just hadn't remembered that I hadn't updated Xen
>> since before the XSA and patch for this had been posted (and it took me
>> a while to remember this when I accidentally panicked Xen :))
> 
> As I'm lazy, both to search and to write something myself: is there
> already a test case for the issue(s) circling around?

To everybody: keep reproducers offlist, please.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-11 Thread Austin S Hemmelgarn 

On 2015-11-11 08:07, Paolo Bonzini wrote:



On 11/11/2015 13:47, Austin S Hemmelgarn wrote:



I just finished running a couple of tests in a KVM instance running
nested on a Xen HVM instance, and found no issues, so for the set as a
whole:

Tested-by: Austin S. Hemmelgarn 

Now to hope the equivalent fix for Xen gets into the Gentoo repositories
soon, as the issue propagates down through nested virtualization and
ties up the CPU regardless (and in turn triggers the watchdog).


Note that nested guests should _not_ lock up the outer (L0) hypervisor
if the outer hypervisor has the fix.  At least this is the case for KVM:
a fixed outer KVM can protect any vulnerable nested (L1) hypervisor from
malicious nested guests.  A vulnerable outer KVM is also protected if
the nested hypervisor has the workaround.

I already knew this, I just hadn't remembered that I hadn't updated Xen 
since before the XSA and patch for this had been posted (and it took me 
a while to remember this when I accidentally panicked Xen :))





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-11 Thread Paolo Bonzini 


On 11/11/2015 13:47, Austin S Hemmelgarn wrote:
>>
> I just finished running a couple of tests in a KVM instance running
> nested on a Xen HVM instance, and found no issues, so for the set as a
> whole:
> 
> Tested-by: Austin S. Hemmelgarn 
> 
> Now to hope the equivalent fix for Xen gets into the Gentoo repositories
> soon, as the issue propagates down through nested virtualization and
> ties up the CPU regardless (and in turn triggers the watchdog).

Note that nested guests should _not_ lock up the outer (L0) hypervisor
if the outer hypervisor has the fix.  At least this is the case for KVM:
a fixed outer KVM can protect any vulnerable nested (L1) hypervisor from
malicious nested guests.  A vulnerable outer KVM is also protected if
the nested hypervisor has the workaround.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-11 Thread Austin S Hemmelgarn 

On 2015-11-10 07:22, Paolo Bonzini wrote:

Yes, these can happen.  The issue is that benign exceptions are
delivered serially, but two of them (#DB and #AC) can also happen
during exception delivery itself.  The subsequent infinite stream
of exceptions causes the processor to never exit guest mode.

Paolo

Eric Northup (1):
   KVM: x86: work around infinite loop in microcode when #AC is delivered

Paolo Bonzini (2):
   KVM: svm: unconditionally intercept #DB
   KVM: x86: rename update_db_bp_intercept to update_bp_intercept

  arch/x86/include/asm/kvm_host.h |  2 +-
  arch/x86/include/uapi/asm/svm.h |  1 +
  arch/x86/kvm/svm.c  | 22 +++---
  arch/x86/kvm/vmx.c  |  7 +--
  arch/x86/kvm/x86.c  |  2 +-
  5 files changed, 19 insertions(+), 15 deletions(-)

I just finished running a couple of tests in a KVM instance running 
nested on a Xen HVM instance, and found no issues, so for the set as a 
whole:


Tested-by: Austin S. Hemmelgarn 

Now to hope the equivalent fix for Xen gets into the Gentoo repositories 
soon, as the issue propagates down through nested virtualization and 
ties up the CPU regardless (and in turn triggers the watchdog).




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-11 Thread Austin S Hemmelgarn 

On 2015-11-10 07:22, Paolo Bonzini wrote:

Yes, these can happen.  The issue is that benign exceptions are
delivered serially, but two of them (#DB and #AC) can also happen
during exception delivery itself.  The subsequent infinite stream
of exceptions causes the processor to never exit guest mode.

Paolo

Eric Northup (1):
   KVM: x86: work around infinite loop in microcode when #AC is delivered

Paolo Bonzini (2):
   KVM: svm: unconditionally intercept #DB
   KVM: x86: rename update_db_bp_intercept to update_bp_intercept

  arch/x86/include/asm/kvm_host.h |  2 +-
  arch/x86/include/uapi/asm/svm.h |  1 +
  arch/x86/kvm/svm.c  | 22 +++---
  arch/x86/kvm/vmx.c  |  7 +--
  arch/x86/kvm/x86.c  |  2 +-
  5 files changed, 19 insertions(+), 15 deletions(-)

I just finished running a couple of tests in a KVM instance running 
nested on a Xen HVM instance, and found no issues, so for the set as a 
whole:


Tested-by: Austin S. Hemmelgarn 

Now to hope the equivalent fix for Xen gets into the Gentoo repositories 
soon, as the issue propagates down through nested virtualization and 
ties up the CPU regardless (and in turn triggers the watchdog).




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-11 Thread Paolo Bonzini 


On 11/11/2015 13:47, Austin S Hemmelgarn wrote:
>>
> I just finished running a couple of tests in a KVM instance running
> nested on a Xen HVM instance, and found no issues, so for the set as a
> whole:
> 
> Tested-by: Austin S. Hemmelgarn 
> 
> Now to hope the equivalent fix for Xen gets into the Gentoo repositories
> soon, as the issue propagates down through nested virtualization and
> ties up the CPU regardless (and in turn triggers the watchdog).

Note that nested guests should _not_ lock up the outer (L0) hypervisor
if the outer hypervisor has the fix.  At least this is the case for KVM:
a fixed outer KVM can protect any vulnerable nested (L1) hypervisor from
malicious nested guests.  A vulnerable outer KVM is also protected if
the nested hypervisor has the workaround.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-11 Thread Austin S Hemmelgarn 

On 2015-11-11 08:07, Paolo Bonzini wrote:



On 11/11/2015 13:47, Austin S Hemmelgarn wrote:



I just finished running a couple of tests in a KVM instance running
nested on a Xen HVM instance, and found no issues, so for the set as a
whole:

Tested-by: Austin S. Hemmelgarn 

Now to hope the equivalent fix for Xen gets into the Gentoo repositories
soon, as the issue propagates down through nested virtualization and
ties up the CPU regardless (and in turn triggers the watchdog).


Note that nested guests should _not_ lock up the outer (L0) hypervisor
if the outer hypervisor has the fix.  At least this is the case for KVM:
a fixed outer KVM can protect any vulnerable nested (L1) hypervisor from
malicious nested guests.  A vulnerable outer KVM is also protected if
the nested hypervisor has the workaround.

I already knew this, I just hadn't remembered that I hadn't updated Xen 
since before the XSA and patch for this had been posted (and it took me 
a while to remember this when I accidentally panicked Xen :))





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-10 Thread Paolo Bonzini 


On 10/11/2015 16:38, Jan Kiszka wrote:
> On 2015-11-10 13:22, Paolo Bonzini wrote:
>> Yes, these can happen.  The issue is that benign exceptions are
>> delivered serially, but two of them (#DB and #AC) can also happen
>> during exception delivery itself.  The subsequent infinite stream
>> of exceptions causes the processor to never exit guest mode.
>>
>> Paolo
>>
>> Eric Northup (1):
>>   KVM: x86: work around infinite loop in microcode when #AC is delivered
>>
>> Paolo Bonzini (2):
>>   KVM: svm: unconditionally intercept #DB
>>   KVM: x86: rename update_db_bp_intercept to update_bp_intercept
>>
>>  arch/x86/include/asm/kvm_host.h |  2 +-
>>  arch/x86/include/uapi/asm/svm.h |  1 +
>>  arch/x86/kvm/svm.c  | 22 +++---
>>  arch/x86/kvm/vmx.c  |  7 +--
>>  arch/x86/kvm/x86.c  |  2 +-
>>  5 files changed, 19 insertions(+), 15 deletions(-)
>>
> 
> So this affects both Intel and AMD CPUs equally? Nice cross-vendor
> "compatibility".

Yes, it's for both.

> And it can only be triggered via #AC and #DB, or also other exceptions
> (that KVM already happens to intercept)?

Yes, these are the sole benign exceptions that can occur during
exception delivery.  All other benign exceptions only occur as the
result of executing instructions.

> You may guess why I'm asking...
> Is any of the issues already documented in a vendor errata?

No idea.  As far as I understood, processor engineers consider this to
be intended behavior (!) though they admit that the outcome for
virtualization is bad.

I don't have a reproducer for this yet (I have only tested the patches
by ensuring that they do not regress on the legal cases), but from what
I heard at least on Intel the #AC injection actually causes a failed
VM-entry...  Yet, nothing in the manual suggests _why_.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-10 Thread Jan Kiszka 
On 2015-11-10 13:22, Paolo Bonzini wrote:
> Yes, these can happen.  The issue is that benign exceptions are
> delivered serially, but two of them (#DB and #AC) can also happen
> during exception delivery itself.  The subsequent infinite stream
> of exceptions causes the processor to never exit guest mode.
> 
> Paolo
> 
> Eric Northup (1):
>   KVM: x86: work around infinite loop in microcode when #AC is delivered
> 
> Paolo Bonzini (2):
>   KVM: svm: unconditionally intercept #DB
>   KVM: x86: rename update_db_bp_intercept to update_bp_intercept
> 
>  arch/x86/include/asm/kvm_host.h |  2 +-
>  arch/x86/include/uapi/asm/svm.h |  1 +
>  arch/x86/kvm/svm.c  | 22 +++---
>  arch/x86/kvm/vmx.c  |  7 +--
>  arch/x86/kvm/x86.c  |  2 +-
>  5 files changed, 19 insertions(+), 15 deletions(-)
> 

So this affects both Intel and AMD CPUs equally? Nice cross-vendor
"compatibility".

And it can only be triggered via #AC and #DB, or also other exceptions
(that KVM already happens to intercept)? You may guess why I'm asking...

Is any of the issues already documented in a vendor errata?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] Infinite loops in microcode while running guests

2015-11-10 Thread Paolo Bonzini 
Yes, these can happen.  The issue is that benign exceptions are
delivered serially, but two of them (#DB and #AC) can also happen
during exception delivery itself.  The subsequent infinite stream
of exceptions causes the processor to never exit guest mode.

Paolo

Eric Northup (1):
  KVM: x86: work around infinite loop in microcode when #AC is delivered

Paolo Bonzini (2):
  KVM: svm: unconditionally intercept #DB
  KVM: x86: rename update_db_bp_intercept to update_bp_intercept

 arch/x86/include/asm/kvm_host.h |  2 +-
 arch/x86/include/uapi/asm/svm.h |  1 +
 arch/x86/kvm/svm.c  | 22 +++---
 arch/x86/kvm/vmx.c  |  7 +--
 arch/x86/kvm/x86.c  |  2 +-
 5 files changed, 19 insertions(+), 15 deletions(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-10 Thread Jan Kiszka 
On 2015-11-10 13:22, Paolo Bonzini wrote:
> Yes, these can happen.  The issue is that benign exceptions are
> delivered serially, but two of them (#DB and #AC) can also happen
> during exception delivery itself.  The subsequent infinite stream
> of exceptions causes the processor to never exit guest mode.
> 
> Paolo
> 
> Eric Northup (1):
>   KVM: x86: work around infinite loop in microcode when #AC is delivered
> 
> Paolo Bonzini (2):
>   KVM: svm: unconditionally intercept #DB
>   KVM: x86: rename update_db_bp_intercept to update_bp_intercept
> 
>  arch/x86/include/asm/kvm_host.h |  2 +-
>  arch/x86/include/uapi/asm/svm.h |  1 +
>  arch/x86/kvm/svm.c  | 22 +++---
>  arch/x86/kvm/vmx.c  |  7 +--
>  arch/x86/kvm/x86.c  |  2 +-
>  5 files changed, 19 insertions(+), 15 deletions(-)
> 

So this affects both Intel and AMD CPUs equally? Nice cross-vendor
"compatibility".

And it can only be triggered via #AC and #DB, or also other exceptions
(that KVM already happens to intercept)? You may guess why I'm asking...

Is any of the issues already documented in a vendor errata?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] Infinite loops in microcode while running guests

2015-11-10 Thread Paolo Bonzini 


On 10/11/2015 16:38, Jan Kiszka wrote:
> On 2015-11-10 13:22, Paolo Bonzini wrote:
>> Yes, these can happen.  The issue is that benign exceptions are
>> delivered serially, but two of them (#DB and #AC) can also happen
>> during exception delivery itself.  The subsequent infinite stream
>> of exceptions causes the processor to never exit guest mode.
>>
>> Paolo
>>
>> Eric Northup (1):
>>   KVM: x86: work around infinite loop in microcode when #AC is delivered
>>
>> Paolo Bonzini (2):
>>   KVM: svm: unconditionally intercept #DB
>>   KVM: x86: rename update_db_bp_intercept to update_bp_intercept
>>
>>  arch/x86/include/asm/kvm_host.h |  2 +-
>>  arch/x86/include/uapi/asm/svm.h |  1 +
>>  arch/x86/kvm/svm.c  | 22 +++---
>>  arch/x86/kvm/vmx.c  |  7 +--
>>  arch/x86/kvm/x86.c  |  2 +-
>>  5 files changed, 19 insertions(+), 15 deletions(-)
>>
> 
> So this affects both Intel and AMD CPUs equally? Nice cross-vendor
> "compatibility".

Yes, it's for both.

> And it can only be triggered via #AC and #DB, or also other exceptions
> (that KVM already happens to intercept)?

Yes, these are the sole benign exceptions that can occur during
exception delivery.  All other benign exceptions only occur as the
result of executing instructions.

> You may guess why I'm asking...
> Is any of the issues already documented in a vendor errata?

No idea.  As far as I understood, processor engineers consider this to
be intended behavior (!) though they admit that the outcome for
virtualization is bad.

I don't have a reproducer for this yet (I have only tested the patches
by ensuring that they do not regress on the legal cases), but from what
I heard at least on Intel the #AC injection actually causes a failed
VM-entry...  Yet, nothing in the manual suggests _why_.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] Infinite loops in microcode while running guests

2015-11-10 Thread Paolo Bonzini 
Yes, these can happen.  The issue is that benign exceptions are
delivered serially, but two of them (#DB and #AC) can also happen
during exception delivery itself.  The subsequent infinite stream
of exceptions causes the processor to never exit guest mode.

Paolo

Eric Northup (1):
  KVM: x86: work around infinite loop in microcode when #AC is delivered

Paolo Bonzini (2):
  KVM: svm: unconditionally intercept #DB
  KVM: x86: rename update_db_bp_intercept to update_bp_intercept

 arch/x86/include/asm/kvm_host.h |  2 +-
 arch/x86/include/uapi/asm/svm.h |  1 +
 arch/x86/kvm/svm.c  | 22 +++---
 arch/x86/kvm/vmx.c  |  7 +--
 arch/x86/kvm/x86.c  |  2 +-
 5 files changed, 19 insertions(+), 15 deletions(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/