linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-crypto@vger.kernel.org
Subject: Re: [PATCH -v5] random: introduce getrandom(2) system call
Date: Thu, 24 Jul 2014 15:02:06 -0400	[thread overview]
Message-ID: <20140724190206.GL6673@thunk.org> (raw)
In-Reply-To: <CALCETrXAA=UzS-pRCo5tKSjSCOP9xfu66BG9QbRefVrovkavhQ@mail.gmail.com>

On Thu, Jul 24, 2014 at 08:21:38AM -0700, Andy Lutomirski wrote:
> >
> > Should we add E<SOMETHING> to be able to deny access to GRND_RANDOM or some
> > future extension ?
> 
> This might actually be needed sooner rather than later.  There are
> programs that use containers and intentionally don't pass /dev/random
> through into the container.  I know that Sandstorm does this, and I
> wouldn't be surprised if other things (Docker?) do the same thing.

I wouldn't add the error to the man page until we actually modify the
kernel to add such a restriction.

However, the thought crossed my mind a while back that perhaps the
right answer is a cgroup controller which controls the rate at which a
process is allowed to drain entropy from the /dev/random pool.  This
could be set to 0, or it could be set to N bits per unit time T, and
if the process exceeded the value, it would just block or return
EAGAIN.  So instead of making it be just a binary "you have access" or
"you don't", it would actually be a kernel resource that could be
controlled just like disk bandwidth, networking bandwidth, memory, and
CPU time.

Then I decided that it was overkill, but for people who are trying to
treat containers as a way to divide up OS resources between mutually
suspicious customers in a fashion which is more efficient thatn using
VM's, maybe it is something that someone will want to implement.

      	       	  	    	 	    	- Ted

  reply	other threads:[~2014-07-24 19:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-24 14:31 [PATCH -v5] random: introduce getrandom(2) system call Theodore Ts'o
2014-07-24 15:18 ` Henrique de Moraes Holschuh
2014-07-24 15:21   ` Andy Lutomirski
2014-07-24 19:02     ` Theodore Ts'o [this message]
2014-07-24 20:30       ` Henrique de Moraes Holschuh
2014-07-24 20:54         ` Andy Lutomirski
2014-07-24 23:27           ` H. Peter Anvin
2014-07-24 23:24         ` Theodore Ts'o
2014-07-24 23:27           ` Andy Lutomirski
     [not found]             ` <CALCETrVgKMVnBuzE+bCXaUPRrqhVxwv4AXmJrUJSYws5rZxhJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-25 13:22               ` Theodore Ts'o
     [not found]           ` <20140724232434.GN6673-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-07-25 12:46             ` Henrique de Moraes Holschuh
     [not found] ` <1406212287-9855-1-git-send-email-tytso-3s7WtUTddSA@public.gmane.org>
2014-07-30 14:34   ` Rolf Eike Beer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140724190206.GL6673@thunk.org \
    --to=tytso@mit.edu \
    --cc=hmh@hmh.eng.br \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).