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
next prev parent 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).