linux-kernel - Re: git pull] drm for v4.1-rc1

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]

Message-ID: <CA+55aFwC+sH+62b4rDuy5PWAPEc9Xr3tWcCAQXOED+2Jk9C65A@mail.gmail.com>
Date:	Thu, 23 Apr 2015 15:47:10 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Garrett <matthew.garrett@...eos.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Dave Airlie <airlied@...ux.ie>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Matthew Garrett <mjg59@...eos.com>
Subject: Re: git pull] drm for v4.1-rc1

On Thu, Apr 23, 2015 at 2:56 PM, Matthew Garrett
<matthew.garrett@...eos.com> wrote:
> On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>>
>>   int pcibios_add_device(struct pci_dev *dev)
>>   {
>>     if (dev-is-default-vga-device) {
>>       dev->rom = 0xC0000;
>>       dev->romlen = 0x20000;
>>     }
>
> I don't know what we want to do here. This is, at some level,
> fundamentally wrong - however, it also wouldn't surprise me if this is
> also the only copy of the video ROM we have on some UEFI systems,
> especially since I believe that Windows 7 still required that there be
> a legacy ROM it could use for bootloader modesetting on UEFI
> platforms. So simply making this conditional on BIOS may break
> existing machines. But if there *is* a ROM there then we should be
> able to id it from the usual video ROM signature?

I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but
yes, if what this is all about is the magic video ROM at 0xc0000, then

 (a) it should have nothing what-so-ever to do with the actual PCI
BAR, since it's been *ages* since people actually had an expansion rom
like that, and it's much more common that the video ROM comes as part
of the system BIOS on laptops etc.

 (b) yes, the sane thing to do would be to just look for the ROM
signature, 0x55 0xaa at 2kB incrementing headers (and checking the
proper checksum too).

There is no way to see that from the PCI device state, because as
mentioned, quite often the "ROM" is entirely fake, and is not just
some shadowed copy of a real underlying hardware ROM, but is
fundamentally just a RAM image decompressed from some other source and
then marked read-only.

                   Linus
--
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/