| Message ID | 20171201182110.7143-1-jmattson@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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>
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 >
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 >>
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 >>>
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 >>>
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 >>>> >
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?
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?
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? >
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);