linux-kernel - Re: [PATCH] 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:	Sat, 19 Jun 2010 10:30:56 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	linux-kernel@...r.kernel.org, dzickus@...hat.com
Subject: Re: [PATCH] Add TAINT_HARDWARE_UNSUPPORTED flag

> Typically, one would push a config patch to enable and disable the feature and
> patch the distribution.  However, in some cases this is not feasible in order

If you can push a patch to set the flag you can push a patch to panic or
reject that combination.

Devil's advocate time: 

Also the fact some distributions chose a binary compatible interface for
their internal modules was their choice. It is one that has been
repeatedly rejected by upstream and at kernel summit.

So given we fundamnetally reject your approach why should we carry your
flag ?

> In some cases the distribution may want to allow booting of these features but
> explicitly notify a user that they are not "officially" supported.  It is also

We have printk. You can add a module of your own which indicates
'support' status too.

> possible that the hardware is fixed via a firmware update at a later date,
> making it supported again.

IMHO it's not properly named in the first place. You are talking about
combinations of hardware/firmware and you actually mean 'configuration
not supported' ?

> This patch introduces the TAINT_HARDWARE_UNSUPPORTED flag for distributions
> to use.

and why KERN_CRIT when the other printk's don't use that level ?

A suggestion: instead of all this push a single patch with a comment and
maybe defines indicating that taint flag bits 28-31 are 'reserved' for
experimental and out of tree applications.

That way anyone who has a requirement like yours can deal with it and
nobody has to worry about bit collisions, naming and the like. Nor if you
suddenely need an extra bit in 3 years time are you going to come unstuck
on your KABI. That will help other people doing experiments with taint or
with differing needs to the Red Hat one.

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/