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:	Fri, 9 Apr 2010 23:51:48 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Yinghai <yinghai.lu@...cle.com>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, linux-pci@...r.kernel.org,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	Andy Isaacson <adi@...apodia.org>,
	Thomas Renninger <trenn@...e.de>
Subject: Re: [PATCH] x86: Reserve legacy VGA MMIO area for x86_64 as well as
 x86_32

> Why is this different for 64-bit vs 32-bit?  Can you point me to any
> references where I can learn about this?

IMHO its wrong for both

You can only reserve the region in question if you actually have a VGA
device and mappings present.

It's wrong for non PCI systems
It's wrong for legacy ISA systems with monochrome video/no video
It's wrong for several embedded platforms.
It's wrong if PCI isn't your root bridge

Basically the reservation is the wrong way to fix it. A much saner way to
fix it would be to simply keep a list of address ranges not to use for
PCI device relocation. For I/O ports of course we just fix up the PCI
resources of the device to list them as we discover it (IDE legacy).

You don't want to put anything at the VGA address that needs assigning an
address. That is *totally* different to the question of whether you want
to believe the space is 'reserved'. If something is at that address then
presumably the firmware knows what it is doing. If a device driver wishes
to reserve that address it's doing so with more information, later in
boot so should be allowed to.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ