Message ID | 1405074278-16230-4-git-send-email-kraxel@redhat.com |
---|---|
State | New |
Headers | show |
Hi Benjamin, On 11.07.2014 12:24, Gerd Hoffmann wrote: > From: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > Commit b2eb849d4b1fdb6f35d5c46958c7f703cf64cfef > "CVE-2007-1320 - Cirrus LGD-54XX "bitblt" heap overflow" broke > cpu to video blits. > > When the ROP function is called from cirrus_bitblt_cputovideo_next(), > we pass 0 for the pitch but only operate on one line at a time. The > added test was tripping because after the initial substraction, the > pitch becomes negative. Make the test only trip when the height is > larger than one (ie. the pitch is actually used). > > This fixes HW cursor support in Windows NT4.0 (which otherwise was > a white rectangle) and general display of icons in that OS when using > 8bpp mode. > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > --- > hw/display/cirrus_vga_rop.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/hw/display/cirrus_vga_rop.h b/hw/display/cirrus_vga_rop.h > index 9c7bb09..0925a00 100644 > --- a/hw/display/cirrus_vga_rop.h > +++ b/hw/display/cirrus_vga_rop.h > @@ -52,8 +52,7 @@ glue(cirrus_bitblt_rop_fwd_, ROP_NAME)(CirrusVGAState *s, > dstpitch -= bltwidth; > srcpitch -= bltwidth; > > - if (dstpitch < 0 || srcpitch < 0) { > - /* is 0 valid? srcpitch == 0 could be useful */ > + if (bltheight > 1 && (dstpitch < 0 || srcpitch < 0)) { > return; > } > it seems you have digged into the cirrus code recently. Have you an idea how to fix the issue with the graphics corruption for cirrus vga and recent X Server versions? E.g. take an Ubuntu 14.04 Desktop CD, boot it into live mode and open terminal. I have tried to debug it a little, but I have no clue how to solve this. I tried to get hands on a real hardware Cirrus Logic Graphics card and test if this happens there as well, but I had no chance to get one. Peter
On Mon, 2014-07-14 at 09:24 +0200, Peter Lieven wrote: > it seems you have digged into the cirrus code recently. Have you an idea how to > fix the issue with the graphics corruption for cirrus vga and recent X Server versions? > > E.g. take an Ubuntu 14.04 Desktop CD, boot it into live mode and open terminal. > > I have tried to debug it a little, but I have no clue how to solve this. I tried to get > hands on a real hardware Cirrus Logic Graphics card and test if this happens there as well, > but I had no chance to get one. I *think* it is a X server side bug. They broke 24bpp packed pixel format. I've seen patches submitted to the Xorg list fairly recently by somebody from canonical. You can test by creating an xorg.conf to force the display to 16bpp instead of 24 and see if that helps. Cheers, Ben.
On Mon, 2014-07-14 at 17:29 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2014-07-14 at 09:24 +0200, Peter Lieven wrote: > > it seems you have digged into the cirrus code recently. Have you an idea how to > > fix the issue with the graphics corruption for cirrus vga and recent X Server versions? > > > > E.g. take an Ubuntu 14.04 Desktop CD, boot it into live mode and open terminal. > > > > I have tried to debug it a little, but I have no clue how to solve this. I tried to get > > hands on a real hardware Cirrus Logic Graphics card and test if this happens there as well, > > but I had no chance to get one. > > I *think* it is a X server side bug. They broke 24bpp packed pixel > format. I've seen patches submitted to the Xorg list fairly recently by > somebody from canonical. > > You can test by creating an xorg.conf to force the display to 16bpp > instead of 24 and see if that helps. Look for patches from "Robert Ancell <robert.ancell@canonical.com>" on the xorg-devel list. In fact I'd suggest you test and report if that works for you, that might give Keithp an incentive for actually merging them :-) Cheers, Ben.
On 14.07.2014 09:29, Benjamin Herrenschmidt wrote: > On Mon, 2014-07-14 at 09:24 +0200, Peter Lieven wrote: >> it seems you have digged into the cirrus code recently. Have you an idea how to >> fix the issue with the graphics corruption for cirrus vga and recent X Server versions? >> >> E.g. take an Ubuntu 14.04 Desktop CD, boot it into live mode and open terminal. >> >> I have tried to debug it a little, but I have no clue how to solve this. I tried to get >> hands on a real hardware Cirrus Logic Graphics card and test if this happens there as well, >> but I had no chance to get one. > I *think* it is a X server side bug. They broke 24bpp packed pixel > format. I've seen patches submitted to the Xorg list fairly recently by > somebody from canonical. > > You can test by creating an xorg.conf to force the display to 16bpp > instead of 24 and see if that helps. Will do, thanks for the pointer. Do you see a way to work around this in the graphics driver. E.g. blacklisting 24bpp modes etc. Even if X.Org people actually merge the fixes there are 2 years of Linux releases out there that have corrupted graphics. Peter
Hi, > Do you see a way to work around this in the graphics driver. E.g. blacklisting 24bpp modes > etc. Even if X.Org people actually merge the fixes there are 2 years of Linux releases out > there that have corrupted graphics. For anything using kernel 3.14+ IMO the answer to pretty much *any* gfx issue is "use stdvga instead of cirrus". 3.14 got a kms driver for the qemu stdvga (bochsdrm), so the modesetting driver and all the modern stuff such as root-less X server works with the stdvga too. And the constrains cirrus has (due to emulating existing, old hardware) are gone. cheers, Gerd
On 14.07.2014 11:53, Gerd Hoffmann wrote: > Hi, > >> Do you see a way to work around this in the graphics driver. E.g. blacklisting 24bpp modes >> etc. Even if X.Org people actually merge the fixes there are 2 years of Linux releases out >> there that have corrupted graphics. > For anything using kernel 3.14+ IMO the answer to pretty much *any* gfx > issue is "use stdvga instead of cirrus". 3.14 got a kms driver for the > qemu stdvga (bochsdrm), so the modesetting driver and all the modern > stuff such as root-less X server works with the stdvga too. And the > constrains cirrus has (due to emulating existing, old hardware) are > gone. Thats good news. For older Linuxs it seems that also -vga vmware is a good alternative. The only thing that is a bit odd is that the X.Org driver automatically switches to the maximum resolution at start. I will eventually add a patch to limit the maximum resolution on the qemu command line. -vga std was also a good choice, but for Win2012(R2) the maximum resolution is at 1024x768 so I had to switch to -vga vmware there as well. Peter
Hi, > > For anything using kernel 3.14+ IMO the answer to pretty much *any* gfx > > issue is "use stdvga instead of cirrus". 3.14 got a kms driver for the > > qemu stdvga (bochsdrm), so the modesetting driver and all the modern > > stuff such as root-less X server works with the stdvga too. And the > > constrains cirrus has (due to emulating existing, old hardware) are > > gone. > > Thats good news. For older Linuxs it seems that also -vga vmware is a good alternative. > The only thing that is a bit odd is that the X.Org driver automatically switches to the maximum > resolution at start. Hmm, it should not to that. bochsdrmfb explicitly orders 1024x768 to the top of the list to make it the default, while keeping the other resolutions available so you can easily switch via xrandr if you want. Note that it also might be some desktop component switching via xrandr, not the xorg modesetting driver. Xorg logfile will probably tell. cheers, Gerd
diff --git a/hw/display/cirrus_vga_rop.h b/hw/display/cirrus_vga_rop.h index 9c7bb09..0925a00 100644 --- a/hw/display/cirrus_vga_rop.h +++ b/hw/display/cirrus_vga_rop.h @@ -52,8 +52,7 @@ glue(cirrus_bitblt_rop_fwd_, ROP_NAME)(CirrusVGAState *s, dstpitch -= bltwidth; srcpitch -= bltwidth; - if (dstpitch < 0 || srcpitch < 0) { - /* is 0 valid? srcpitch == 0 could be useful */ + if (bltheight > 1 && (dstpitch < 0 || srcpitch < 0)) { return; }