linux-kernel - Re: pci_fixup_video change blows up on sparc64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Oct 2006 11:03:11 -0700
From:	Jesse Barnes <jesse.barnes@...el.com>
To:	eiichiro.oiwa.nm@...achi.com
Cc:	"David Miller" <davem@...emloft.net>, alan@...hat.com,
	greg@...ah.com, linux-kernel@...r.kernel.org
Subject: Re: pci_fixup_video change blows up on sparc64

On Thursday, October 19, 2006 3:01 am, eiichiro.oiwa.nm@...achi.com 
wrote:
> >> If an expansion ROM exists on ATI Radeon or ATY128 card,
> >> pci_map_rom returns the expansion ROM base address instead of
> >> 0xC0000 because fixup_video checks the VGA Enable bit in the
> >> Bridge Control register.
> >
> >It is not valid to expect the bridge control register to return
> >anything meaningful on PCI "host bridge".  The Radeon card here sits
> >on the root, just under the PCI Host Controller.  The code in
> >fixup_video appears to assume that every bus up to the root from
> >the VGA device is a PCI-PCI bridge, which is not a valid assumption.
> >There can be a PCI host bridge at the root.
>
> Have you ever read the PCI-to-PCI Bridge Architecture Specification?
> The default of VGA Enable bit is 0. This mean video ROM doesn't
> forward system RAM at 0xC0000.
>
> There is your VGA card under 0001:00:00.0 Host bridge. The VGA Enable
> bit in this host bridge will return 0 and IORESOURCE_ROM_SHADOW won't
> set.

I don't think that applies to host->pci bridges though, all bets are off 
as to how their bits are defined.  One check that might make this 
feature a bit more robust is to look for a real PCI ROM on the device.  
If present, we probably don't need to bother with the system copy 
(which probably won't be there anyway).

We should probably also check whether the parent bridge of the device to 
be fixed up is a real pci->pci bridge (if possible).  That would remove 
some ambiguity that's likely to cause problems with other platforms 
too.

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