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]

Date:	Tue, 22 Jun 2010 17:57:41 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	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, 22 Jun 2010 17:38:17 +0100
Matthew Garrett <mjg@...hat.com> wrote:

> On Tue, Jun 22, 2010 at 04:48:35PM +0100, Alan Cox wrote:
> > > +	printk(KERN_CRIT "UNSUPPORTED HARDWARE DEVICE: %s\n", msg);
> > > +	WARN_TAINT(1, TAINT_HARDWARE_UNSUPPORTED,
> > > +		   "Your hardware is unsupported.  Please do not report "
> > > +		   "bugs, panics, oopses, etc., on this hardware.\n");
> > 
> > And as already pointed out it's not unsupported hardware even in the case
> > you described
> 
> It's hardware that isn't supported by the vendor. How is it not 
> unsupported hardware in that context?

Which vendor ? What do you mean by support ? Even in Red Hat you will
I suspect need to change that message because after the first 500 calls
received by Dell or HP or whoever about it they'll demand you add
"unsupported by Red Hat" or similar to avoid them getting support calls !

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 trouble in part is that the moment you borrow a bit for Red Hat
private use and put that use into the kernel you've made it unusuable for
anyone else. If you simply mark a few bits 'private/experimental use'
then you can use it for "unsupported" but others can use it for things
like 'uncertified configuration' or 'test' or 'non vendor signed module
loaded' and so on. All valid uses in specific vendor customisations.

The other giggle of course is that the WARN says do not report, but the
existing oops capturing software will capture the WARN so auto-report it.

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/