linux-kernel - Re: [PATCH 0/3] arch: fix ioport mapping on mips,sh

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: <201201301609.56105.arnd@arndb.de>
Date:	Mon, 30 Jan 2012 16:09:55 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Kevin Cernekee <cernekee@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Myron Stowe <myron.stowe@...hat.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Lucas De Marchi <lucas.demarchi@...fusion.mobi>,
	Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
	James Morris <jmorris@...ei.org>,
	"John W. Linville" <linville@...driver.com>,
	Michael Witten <mfwitten@...il.com>, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org, linux-sh@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH 0/3] arch: fix ioport mapping on mips,sh

On Monday 30 January 2012, Michael S. Tsirkin wrote:
> Kevin Cernekee reported that recent cleanup
> that replaced pci_iomap with a generic function
> failed to take into account the differences
> in io port handling on mips and sh architectures.
> 
> Rather than revert the changes reintroducing the
> code duplication, this patchset fixes this
> by adding ability for architectures to override
> ioport mapping for pci devices.
> 
> I put this in my tree that feeds into linux-next
> and intend to ask Linus to pull this fix if this
> doesn't cause any issues and there are no objections.
> 
> The patches were tested on x86 and compiled on mips and sh.
> Would appreciate reviews/acks/testing reports.

Looks good to me, except for the one detail I've commented
on in the third patch.

Acked-by: Arnd Bergmann <arnd@...db.de>

I do wonder if the sh and mips implementations are robust enough however
(independent of your work): It seems that an ioport number is treated
differently in pci_iomap than it is using ioport_map and inb/outb,
the assumption being that the port number is a local index per PCI domain.
This would mean that any port access other than pci_iomap would only
work on the primary PCI domain. There are two IMHO better solutions that
I've seen on other architectures:

1. create a larger (e.g. 1MB) io port mapping range in virtual memory
that is split into 64kb per domain, and use the domain number to
find the per domain range when setting the resources. Port numbers will
be larger than 65535 this way, but PCI will ignore the upper address
bits for any access so it works fine.

2. split the 64kb io port range into subsections per domain (on page
granularity, e.g. 2 domains with 32kb or at most 16 domains with 4kb)
and map them virtually contiguous, then reassign all io port resources
so that only the correct region for each domain is used.

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