linux-kernel - Re: [discuss] Re: Please pull x86-64 bug fixes

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: <Pine.LNX.4.64.0610051536590.3952@g5.osdl.org>
Date:	Thu, 5 Oct 2006 15:45:22 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Andi Kleen <ak@...e.de>, discuss@...-64.org,
	linux-kernel@...r.kernel.org
Subject: Re: [discuss] Re: Please pull x86-64 bug fixes

On Thu, 5 Oct 2006, Jeff Garzik wrote:

> Andi Kleen wrote:
> > If the choice is between a secret NDA only card with dubious
> > functionality and booting on lots of modern boards I know what to choose.
> 
> That's a strawman argument.  There is no need to choose.  You can clearly boot
> on lots of modern boards with mmconfig just fine.  We just need to narrow down
> which ones.

Jeff, _that_ is the strawman argument.

The thing is, nobody has been able to so far come up with a way to narrow 
down which ones.

I think Andi's response was quite on the mark: if you have a patch to 
narrow it down, please share. Until then, the fact is, we don't know 
_how_, and you're barking up the wrong tree.

It is entirely possible that the only reasonable solution is to 
potentially _never_ use MMIO as the main config mechanism (where "never" 
is "in the next few years" - at some point we may be able to just say 
"screw it, we don't care any more"), and that the drivers that want to use 
MMIO for config accesses will have to use special operations for that.

In other words, right now we have

	int pci_read_config_byte(struct pci_dev *dev, int where, u8 *val)

and maybe we will simply have to add a totally new function like

	int pci_read_mmio_config_byte(struct pci_dev *dev, int where, u8 *val)

for drivers that literally _require_ the mmio accesses for one reason or 
another.

Alternatively, we could just have a "ioremap()" kind of thing, and use 
readl/writel on the end result, ie maybe we could do

	void __iomem *cfg = mmiocfg_remap(dev);

	if (!cfg) {
		printk("MMIO PCI configuration cycles not supported\n");
		return -EIO;
	}

	/* Read the extended error register or some-such crud.. */
	val = readl(cfg + 0x180);
	..

See?  The thign is, at least right now the _advantages_ of MMIOCFG are 
basically zero for all regular hardware, and as such the disadvantages (in 
the form of machines that hang on device discovery) are way way _way_ 
bigger, and no way will do start using MMIO config cycles by default just 
because some unreleased hardware might want to.

But using them explicitly in drivers - that's another thing.

What do you think about this simple solution?

		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/