linux-kernel - Getrandom wrapper

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:	Sun, 25 Oct 2015 09:40:00 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Florian Weimer <fweimer@...hat.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Paul Turner <pjt@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Li Zefan <lizefan@...wei.com>,
	cgroups <cgroups@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	kernel-team <kernel-team@...com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Getrandom wrapper

On Sun, Oct 25, 2015 at 02:17:23PM +0100, Florian Weimer wrote:
> 
> I think we can reach consensus for an implementation which makes this code
> 
>   unsigned char session_key[32];
>   getrandom (session_key, sizeof (session_key), 0);
>   install_session_key (session_key);
> 
> correct.  That is, no error handling code for ENOMEM, ENOSYS, EINTR,
> ENOMEM or short reads is necessary.  It seems that several getrandom
> wrappers currently built into applications do not get this completely right.

The only error handling code that is necessary is a fallback for
ENOSYS.  getrandom(2) won't return ENOMEM, and if the number of bytes
requested is less than or equal to 256 bytes, it won't return EINTR
either.  If the user requests more than 256 bytes, they're doing
something insane and almost certainly not cryptographic, and so
letting it be interruptible should be fine.  (OpenBSD will outright
*fail* a request greater than 256 bytes with an EIO error in their
getentropy(2) system call.  But that means the insane application
won't get any randomness at all in their overly large, insane request,
and if they're that insane, they're probably not checking error
conditions either.)

As far as ENOSYS is concerned, a fallback gets tricky; you could try
to open /dev/urandom, and read from it, but that can fail due to
EMFILE, ENFILE, ENOENT (if they are chrooted and /dev wasn't properly
populated).  So attempting a fallback for ENOSYS can actually expand
the number of potential error conditions for the userspace application
to (fail to) handle.  I suppose you could attempt the fallback and
call abort(2) if the fallback fails, which is probably the safe and
secure thing to do, but applications might not appreciate getting
terminated without getting a chance to do something (but if the
something is just calling random(3), maybe not giving them a chance to
do something insane is the appropriate thing to do....)

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