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: <20120713030325.GB12245@thunk.org>
Date:	Thu, 12 Jul 2012 23:03:25 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Rob Landley <rob@...dley.net>
Cc:	LKML <linux-kernel@...r.kernel.org>, rgetz@...ckfin.uclinux.org,
	mpm@...enic.com
Subject: Re: feature-removal-schedule entry from 2009

On Wed, Jul 11, 2012 at 11:15:20AM -0500, Rob Landley wrote:
> IRQF_SAMPLE_RANDOM is 3 years past its sell-by date in
> feature-removal-schedule:
> 
> What:   IRQF_SAMPLE_RANDOM
> Check:  IRQF_SAMPLE_RANDOM
> When:   July 2009
> 
> Why:    Many of IRQF_SAMPLE_RANDOM users are technically bogus as
>         entropy sources in the kernel's current entropy model. To
>         resolve this, every input point to the kernel's entropy pool
>         needs to better document the type of entropy source it actually
>         is. This will be replaced with additional add_*_randomness
>         functions in drivers/char/random.c
> 
> Who:    Robin Getz <rgetz@...ckfin.uclinux.org>
>         & Matt Mackall <mpm@...enic.com>
> 
> There are 12 remaining uses under drivers/ and 14 more under arch/, the
> rest of the hits look like infrastructure implementing it.
> 
> Should I run those files through bother-maintainer.pl and try to get
> people to stop it, or is there a plan underway I don't know about?

I was going to deal with that in the new /dev/random tree; once those
changes go in, IRQF_SAMPLE_RANDOM effectively becomes a no-op.  But
I'd prefer that the ordering be that we get the new
sample_interrupt_randomness() changes in first, and then remove the
IRQF_SAMPLE_RANDOM.

I've just been slammed with work, processing patches for the ext4
merge window, and kernel summit planning, and quite frankly, I
considered this to be relatively low priority --- especially since we
no shortage of IRQF_* flag bits, and once the new
sample_interrupt_randomness() goes in, the flag is a complete no-op.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ