linux-kernel - Re: [PATCH v3] Add TAINT_HARDWARE

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: <20100623030637.GA30139@linux-sh.org>
Date:	Wed, 23 Jun 2010 12:06:38 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Don Zickus <dzickus@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Prarit Bhargava <prarit@...hat.com>,
	linux-kernel@...r.kernel.org,
	Randy Dunlap <randy.dunlap@...cle.com>
Subject: Re: [PATCH v3] Add TAINT_HARDWARE_UNSUPPORTED flag

On Tue, Jun 22, 2010 at 06:04:10PM +0100, Matthew Garrett wrote:
> On Tue, Jun 22, 2010 at 05:57:41PM +0100, Alan Cox wrote:
> 
> > And then as I said originally the example given was not even
> > "unsupported hardware" for an obvious Red Hat definition of the two
> > because it was actually about firmware combinations on specific boards -
> > ie it was an unsupported configuration.
> 
> The two examples given were:
> 
> "a distribution may want to support PPC but not the Power5 chipset, or 
> the e1000e driver but not a card with a specific DeviceID because of 
> known firmware issues."
> 
> In both those cases it's specific hardware that's unsupported, not the 
> configuration.
> 
What exactly is the use case supposed to be? If drivers are supposed to
call in to it for specific devices then they already have all of the
information they need for constructing a device blacklist and providing
more detailed information. If it's a configuration issue then we have
device quirks, which could also be extended to other busses as needed. In
either case, the context ought to be fairly explicit. I would much rather
see a message from the bus code stating that a specific device has been
disabled and skip the probe path entirely rather than trying to bolt on a
system-wide unsupported hardware state.
--
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/