[1/2] KVM: VMX: remove I/O port 0x80 bypass on Intel hosts
diff mbox

Message ID 20171201182110.7143-1-jmattson@google.com
State New
Headers show

Commit Message

Jim Mattson Dec. 1, 2017, 6:21 p.m. UTC
From: Andrew Honig <ahonig@google.com>

This fixes CVE-2017-1000407.

KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
the guest floods this port with writes it generates exceptions and
instability in the host kernel, leading to a crash.  With this change
guest writes to port 0x80 on Intel will behave the same as they
currently behave on AMD systems.

Prevent the flooding by removing the code that sets port 0x80 as a
passthrough port.  This is essentially the same as upstream patch
99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
for AMD chipsets and this patch is for Intel.

Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
---
 arch/x86/kvm/vmx.c | 5 -----
 1 file changed, 5 deletions(-)

Comments

Krish Sadhukhan Dec. 2, 2017, 12:34 a.m. UTC | #1
On 12/01/2017 10:21 AM, Jim Mattson wrote:
> From: Andrew Honig <ahonig@google.com>
>
> This fixes CVE-2017-1000407.
>
> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
> the guest floods this port with writes it generates exceptions and
> instability in the host kernel, leading to a crash.  With this change
> guest writes to port 0x80 on Intel will behave the same as they
> currently behave on AMD systems.
>
> Prevent the flooding by removing the code that sets port 0x80 as a
> passthrough port.  This is essentially the same as upstream patch
> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
> for AMD chipsets and this patch is for Intel.
>
> Signed-off-by: Andrew Honig <ahonig@google.com>
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---
>   arch/x86/kvm/vmx.c | 5 -----
>   1 file changed, 5 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index d2b452d66363..d16abd1808eb 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6753,12 +6753,7 @@ static __init int hardware_setup(void)
>   	memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
>   	memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
>   
> -	/*
> -	 * Allow direct access to the PC debug port (it is often used for I/O
> -	 * delays, but the vmexits simply slow things down).
> -	 */
>   	memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE);
> -	clear_bit(0x80, vmx_io_bitmap_a);
>   
>   	memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE);
>   
Reviewed-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Wanpeng Li Dec. 4, 2017, 12:44 p.m. UTC | #2
Hi Jim,
2017-12-02 2:21 GMT+08:00 Jim Mattson <jmattson@google.com>:
> From: Andrew Honig <ahonig@google.com>
>
> This fixes CVE-2017-1000407.

Do you observe a real issue on recent Intel boxes? In addition, how to
reproduce? Actually there is a testcase in kvm-unit-tests which can
run 10 million times ioport 0x80 write and I didn't observe any issue
before. :)

Regards,
Wanpeng Li

>
> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
> the guest floods this port with writes it generates exceptions and
> instability in the host kernel, leading to a crash.  With this change
> guest writes to port 0x80 on Intel will behave the same as they
> currently behave on AMD systems.
>
> Prevent the flooding by removing the code that sets port 0x80 as a
> passthrough port.  This is essentially the same as upstream patch
> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
> for AMD chipsets and this patch is for Intel.
>
> Signed-off-by: Andrew Honig <ahonig@google.com>
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---
>  arch/x86/kvm/vmx.c | 5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index d2b452d66363..d16abd1808eb 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -6753,12 +6753,7 @@ static __init int hardware_setup(void)
>         memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
>         memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
>
> -       /*
> -        * Allow direct access to the PC debug port (it is often used for I/O
> -        * delays, but the vmexits simply slow things down).
> -        */
>         memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE);
> -       clear_bit(0x80, vmx_io_bitmap_a);
>
>         memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE);
>
> --
> 2.15.0.531.g2ccb3012c9-goog
>
Jim Mattson Dec. 4, 2017, 5:10 p.m. UTC | #3
Google has carried this patch since long before my time. I would
suggest modifying the kvm-unit-test to (a) unroll the loop ~1000
times, and (b) execute out to port 0x80 from ~64 vcpu threads in
parallel.

On Mon, Dec 4, 2017 at 4:44 AM, Wanpeng Li <kernellwp@gmail.com> wrote:
> Hi Jim,
> 2017-12-02 2:21 GMT+08:00 Jim Mattson <jmattson@google.com>:
>> From: Andrew Honig <ahonig@google.com>
>>
>> This fixes CVE-2017-1000407.
>
> Do you observe a real issue on recent Intel boxes? In addition, how to
> reproduce? Actually there is a testcase in kvm-unit-tests which can
> run 10 million times ioport 0x80 write and I didn't observe any issue
> before. :)
>
> Regards,
> Wanpeng Li
>
>>
>> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
>> the guest floods this port with writes it generates exceptions and
>> instability in the host kernel, leading to a crash.  With this change
>> guest writes to port 0x80 on Intel will behave the same as they
>> currently behave on AMD systems.
>>
>> Prevent the flooding by removing the code that sets port 0x80 as a
>> passthrough port.  This is essentially the same as upstream patch
>> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
>> for AMD chipsets and this patch is for Intel.
>>
>> Signed-off-by: Andrew Honig <ahonig@google.com>
>> Signed-off-by: Jim Mattson <jmattson@google.com>
>> ---
>>  arch/x86/kvm/vmx.c | 5 -----
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index d2b452d66363..d16abd1808eb 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -6753,12 +6753,7 @@ static __init int hardware_setup(void)
>>         memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
>>         memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
>>
>> -       /*
>> -        * Allow direct access to the PC debug port (it is often used for I/O
>> -        * delays, but the vmexits simply slow things down).
>> -        */
>>         memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE);
>> -       clear_bit(0x80, vmx_io_bitmap_a);
>>
>>         memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE);
>>
>> --
>> 2.15.0.531.g2ccb3012c9-goog
>>
Wanpeng Li Dec. 5, 2017, 7:19 a.m. UTC | #4
2017-12-05 1:10 GMT+08:00 Jim Mattson <jmattson@google.com>:
> Google has carried this patch since long before my time. I would
> suggest modifying the kvm-unit-test to (a) unroll the loop ~1000
> times, and (b) execute out to port 0x80 from ~64 vcpu threads in
> parallel.

Thanks for the information. :)

Regards,
Wanpeng Li

>
> On Mon, Dec 4, 2017 at 4:44 AM, Wanpeng Li <kernellwp@gmail.com> wrote:
>> Hi Jim,
>> 2017-12-02 2:21 GMT+08:00 Jim Mattson <jmattson@google.com>:
>>> From: Andrew Honig <ahonig@google.com>
>>>
>>> This fixes CVE-2017-1000407.
>>
>> Do you observe a real issue on recent Intel boxes? In addition, how to
>> reproduce? Actually there is a testcase in kvm-unit-tests which can
>> run 10 million times ioport 0x80 write and I didn't observe any issue
>> before. :)
>>
>> Regards,
>> Wanpeng Li
>>
>>>
>>> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
>>> the guest floods this port with writes it generates exceptions and
>>> instability in the host kernel, leading to a crash.  With this change
>>> guest writes to port 0x80 on Intel will behave the same as they
>>> currently behave on AMD systems.
>>>
>>> Prevent the flooding by removing the code that sets port 0x80 as a
>>> passthrough port.  This is essentially the same as upstream patch
>>> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
>>> for AMD chipsets and this patch is for Intel.
>>>
>>> Signed-off-by: Andrew Honig <ahonig@google.com>
>>> Signed-off-by: Jim Mattson <jmattson@google.com>
>>> ---
>>>  arch/x86/kvm/vmx.c | 5 -----
>>>  1 file changed, 5 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> index d2b452d66363..d16abd1808eb 100644
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -6753,12 +6753,7 @@ static __init int hardware_setup(void)
>>>         memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
>>>         memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
>>>
>>> -       /*
>>> -        * Allow direct access to the PC debug port (it is often used for I/O
>>> -        * delays, but the vmexits simply slow things down).
>>> -        */
>>>         memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE);
>>> -       clear_bit(0x80, vmx_io_bitmap_a);
>>>
>>>         memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE);
>>>
>>> --
>>> 2.15.0.531.g2ccb3012c9-goog
>>>
Quan Xu Dec. 5, 2017, 11:24 a.m. UTC | #5
On 2017/12/05 01:10, Jim Mattson wrote:
> Google has carried this patch since long before my time. I would
> suggest modifying the kvm-unit-test to (a) unroll the loop ~1000
> times, and (b) execute out to port 0x80 from ~64 vcpu threads in
> parallel.

Jim,  could you reproduce it on all of your machine types?
I can't reproduce it on 2 types of my machine.. btw, it is not a good 
idle to
open reproduction here:(..

I do believe you can reproduce on you machine. could you have a try:
without guest, flood 80 port with writes in host kernel..  does it lead 
to a crash?
if host kernel crash, does it a machine hardware issue, kernel issue, or 
both?


Quan
Alibaba Cloud


> On Mon, Dec 4, 2017 at 4:44 AM, Wanpeng Li <kernellwp@gmail.com> wrote:
>> Hi Jim,
>> 2017-12-02 2:21 GMT+08:00 Jim Mattson <jmattson@google.com>:
>>> From: Andrew Honig <ahonig@google.com>
>>>
>>> This fixes CVE-2017-1000407.
>> Do you observe a real issue on recent Intel boxes? In addition, how to
>> reproduce? Actually there is a testcase in kvm-unit-tests which can
>> run 10 million times ioport 0x80 write and I didn't observe any issue
>> before. :)
>>
>> Regards,
>> Wanpeng Li
>>
>>> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
>>> the guest floods this port with writes it generates exceptions and
>>> instability in the host kernel, leading to a crash.  With this change
>>> guest writes to port 0x80 on Intel will behave the same as they
>>> currently behave on AMD systems.
>>>
>>> Prevent the flooding by removing the code that sets port 0x80 as a
>>> passthrough port.  This is essentially the same as upstream patch
>>> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
>>> for AMD chipsets and this patch is for Intel.
>>>
>>> Signed-off-by: Andrew Honig <ahonig@google.com>
>>> Signed-off-by: Jim Mattson <jmattson@google.com>
>>> ---
>>>   arch/x86/kvm/vmx.c | 5 -----
>>>   1 file changed, 5 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> index d2b452d66363..d16abd1808eb 100644
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -6753,12 +6753,7 @@ static __init int hardware_setup(void)
>>>          memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
>>>          memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
>>>
>>> -       /*
>>> -        * Allow direct access to the PC debug port (it is often used for I/O
>>> -        * delays, but the vmexits simply slow things down).
>>> -        */
>>>          memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE);
>>> -       clear_bit(0x80, vmx_io_bitmap_a);
>>>
>>>          memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE);
>>>
>>> --
>>> 2.15.0.531.g2ccb3012c9-goog
>>>
Wanpeng Li Dec. 5, 2017, 12:15 p.m. UTC | #6
2017-12-05 19:24 GMT+08:00 Quan Xu <quan.xu0@gmail.com>:
>
>
> On 2017/12/05 01:10, Jim Mattson wrote:
>>
>> Google has carried this patch since long before my time. I would
>> suggest modifying the kvm-unit-test to (a) unroll the loop ~1000
>> times, and (b) execute out to port 0x80 from ~64 vcpu threads in
>> parallel.
>
>
> Jim,  could you reproduce it on all of your machine types?
> I can't reproduce it on 2 types of my machine.. btw, it is not a good idle
> to
> open reproduction here:(..

My fault, however, luckily, we still can't reproduce by the method
which Jim pointed out. :)

Regards,
Wanpeng Li

>
> I do believe you can reproduce on you machine. could you have a try:
> without guest, flood 80 port with writes in host kernel..  does it lead to a
> crash?
> if host kernel crash, does it a machine hardware issue, kernel issue, or
> both?
>
>
> Quan
> Alibaba Cloud
>
>
>
>> On Mon, Dec 4, 2017 at 4:44 AM, Wanpeng Li <kernellwp@gmail.com> wrote:
>>>
>>> Hi Jim,
>>> 2017-12-02 2:21 GMT+08:00 Jim Mattson <jmattson@google.com>:
>>>>
>>>> From: Andrew Honig <ahonig@google.com>
>>>>
>>>> This fixes CVE-2017-1000407.
>>>
>>> Do you observe a real issue on recent Intel boxes? In addition, how to
>>> reproduce? Actually there is a testcase in kvm-unit-tests which can
>>> run 10 million times ioport 0x80 write and I didn't observe any issue
>>> before. :)
>>>
>>> Regards,
>>> Wanpeng Li
>>>
>>>> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
>>>> the guest floods this port with writes it generates exceptions and
>>>> instability in the host kernel, leading to a crash.  With this change
>>>> guest writes to port 0x80 on Intel will behave the same as they
>>>> currently behave on AMD systems.
>>>>
>>>> Prevent the flooding by removing the code that sets port 0x80 as a
>>>> passthrough port.  This is essentially the same as upstream patch
>>>> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
>>>> for AMD chipsets and this patch is for Intel.
>>>>
>>>> Signed-off-by: Andrew Honig <ahonig@google.com>
>>>> Signed-off-by: Jim Mattson <jmattson@google.com>
>>>> ---
>>>>   arch/x86/kvm/vmx.c | 5 -----
>>>>   1 file changed, 5 deletions(-)
>>>>
>>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>>> index d2b452d66363..d16abd1808eb 100644
>>>> --- a/arch/x86/kvm/vmx.c
>>>> +++ b/arch/x86/kvm/vmx.c
>>>> @@ -6753,12 +6753,7 @@ static __init int hardware_setup(void)
>>>>          memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
>>>>          memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
>>>>
>>>> -       /*
>>>> -        * Allow direct access to the PC debug port (it is often used
>>>> for I/O
>>>> -        * delays, but the vmexits simply slow things down).
>>>> -        */
>>>>          memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE);
>>>> -       clear_bit(0x80, vmx_io_bitmap_a);
>>>>
>>>>          memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE);
>>>>
>>>> --
>>>> 2.15.0.531.g2ccb3012c9-goog
>>>>
>
Radim Krčmář Dec. 5, 2017, 9:32 p.m. UTC | #7
2017-12-01 10:21-0800, Jim Mattson:
> From: Andrew Honig <ahonig@google.com>
> 
> This fixes CVE-2017-1000407.
> 
> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
> the guest floods this port with writes it generates exceptions and
> instability in the host kernel, leading to a crash.  With this change
> guest writes to port 0x80 on Intel will behave the same as they
> currently behave on AMD systems.
> 
> Prevent the flooding by removing the code that sets port 0x80 as a
> passthrough port.  This is essentially the same as upstream patch
> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
> for AMD chipsets and this patch is for Intel.
> 
> Signed-off-by: Andrew Honig <ahonig@google.com>
> Signed-off-by: Jim Mattson <jmattson@google.com>

Fixes: fdef3ad1b386 ("KVM: VMX: Enable io bitmaps to avoid IO port 0x80 VMEXITs")
Cc: <stable@vger.kernel.org>

Applied, thanks.  The commit that introduced it boasted 3-5% performance
improvements when compiling the kernel -- have you noticed regressions?
Jim Mattson Dec. 6, 2017, 12:36 a.m. UTC | #8
I don't think I believe the performance claim of the original
commit...unless the kernel build test was spewing its output onto a
serial port, in which case the performance claim is mischaracterized.

On Tue, Dec 5, 2017 at 1:32 PM, Radim Krčmář <rkrcmar@redhat.com> wrote:
> 2017-12-01 10:21-0800, Jim Mattson:
>> From: Andrew Honig <ahonig@google.com>
>>
>> This fixes CVE-2017-1000407.
>>
>> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
>> the guest floods this port with writes it generates exceptions and
>> instability in the host kernel, leading to a crash.  With this change
>> guest writes to port 0x80 on Intel will behave the same as they
>> currently behave on AMD systems.
>>
>> Prevent the flooding by removing the code that sets port 0x80 as a
>> passthrough port.  This is essentially the same as upstream patch
>> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
>> for AMD chipsets and this patch is for Intel.
>>
>> Signed-off-by: Andrew Honig <ahonig@google.com>
>> Signed-off-by: Jim Mattson <jmattson@google.com>
>
> Fixes: fdef3ad1b386 ("KVM: VMX: Enable io bitmaps to avoid IO port 0x80 VMEXITs")
> Cc: <stable@vger.kernel.org>
>
> Applied, thanks.  The commit that introduced it boasted 3-5% performance
> improvements when compiling the kernel -- have you noticed regressions?
Quan Xu Dec. 6, 2017, 1:38 a.m. UTC | #9
On 2017/12/06 05:32, Radim Krčmář wrote:
> 2017-12-01 10:21-0800, Jim Mattson:
>> From: Andrew Honig <ahonig@google.com>
>>
>> This fixes CVE-2017-1000407.
>>
>> KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
>> the guest floods this port with writes it generates exceptions and
>> instability in the host kernel, leading to a crash.  With this change
>> guest writes to port 0x80 on Intel will behave the same as they
>> currently behave on AMD systems.
>>
>> Prevent the flooding by removing the code that sets port 0x80 as a
>> passthrough port.  This is essentially the same as upstream patch
>> 99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
>> for AMD chipsets and this patch is for Intel.
>>
>> Signed-off-by: Andrew Honig <ahonig@google.com>
>> Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Quan Xu <quan.xu0@gmail.com>


Quan
Alibaba Cloud
> Fixes: fdef3ad1b386 ("KVM: VMX: Enable io bitmaps to avoid IO port 0x80 VMEXITs")
> Cc: <stable@vger.kernel.org>
>
> Applied, thanks.  The commit that introduced it boasted 3-5% performance
> improvements when compiling the kernel -- have you noticed regressions?
>

Patch
diff mbox

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d2b452d66363..d16abd1808eb 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6753,12 +6753,7 @@  static __init int hardware_setup(void)
 	memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
 	memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
 
-	/*
-	 * Allow direct access to the PC debug port (it is often used for I/O
-	 * delays, but the vmexits simply slow things down).
-	 */
 	memset(vmx_io_bitmap_a, 0xff, PAGE_SIZE);
-	clear_bit(0x80, vmx_io_bitmap_a);
 
 	memset(vmx_io_bitmap_b, 0xff, PAGE_SIZE);