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
| ||
|
Date: Fri, 23 Jan 2015 14:04:01 -0600 From: Tom Zanussi <tom.zanussi@...ux.intel.com> To: Theodore Ts'o <tytso@....edu>, josh@...htriplett.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 10/10] drivers/char: Support compiling out the getrandom(2) syscall On 01/23/2015 01:46 PM, Theodore Ts'o wrote: > On Fri, Jan 23, 2015 at 12:37:16PM -0600, Tom Zanussi wrote: >> Many embedded systems have no use for getrandom, and could benefit >> from the size savings gained by omitting it. Add a new EXPERT config >> option, CONFIG_GETRANDOM_SYSCALL (default y), to support compiling it >> out. > > I'm really not sure this is a good idea. Even the tiniest embedded > device need secure crypto. In fact, one could argue that in the case > of the Internet of Things, the tiniests embedded devices > **especially** need secure crypto. It would be.... unfortunate.... if > the next time North Korea gets upset at the Great Satan, that all of > our light bulbs, refridgerators, cars, heating systems, etc., are > subject to attack. > Right, but not everything is networked - there are standalone embedded systems that could benefit from the savings. Anyway, it's not a huge savings so I could just remove them to avoid the temptation... Tom. > We know already that home routers are running ancient kernels that are > absolutely no protection whatever. Is saving a few bytes really worth > potentially opening up a similar attack vector on devices that will > probably be at least an order of magnitude or more numerous than home > routers, and even harder to upgrade once they get out there? > > And if you don't have a good random number generator, you really are > *toast*. > > It's for this reason that /dev/[u]random were not eligible from being > disabled from the very beginning; it's too much of an attractive > nuisance to a clueless product manager.... > > - 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