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: 15+ 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
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
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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.