Andy you seem to be arguing here for two system calls.
get_urandom() and get_random().
Where get_urandom only blocks if there is not enough starting entropy,
and get_random(GRND_RANDOM) blocks if there is currently not enough
entropy.
That would allow -ENOSYS to be the right return value
We sort of have one. It's called capable(). Just needs extending to cover
anything else you care about, and probably all the numeric constants
replacing with textual names.
Except that it's all backwards: these are things that default to *on*,
and people might want them to turn off.
On Wed, 30 Jul 2014 11:41:41 -0700
ebied...@xmission.com (Eric W. Biederman) wrote:
One Thousand Gnomes gno...@lxorguk.ukuu.org.uk writes:
Andy you seem to be arguing here for two system calls.
get_urandom() and get_random().
Where get_urandom only blocks if there is not enough
One Thousand Gnomes gno...@lxorguk.ukuu.org.uk writes:
On Wed, 30 Jul 2014 11:41:41 -0700
ebied...@xmission.com (Eric W. Biederman) wrote:
One Thousand Gnomes gno...@lxorguk.ukuu.org.uk writes:
Andy you seem to be arguing here for two system calls.
get_urandom() and get_random().
On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote:
There is recent interest in having a way to turn generally-available
kernel features off. Maybe we should add a good one so we can stop
bikeshedding and avoid proliferating dumb interfaces.
I believe the seccomp infrastructure
On Jul 27, 2014 5:06 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote:
There is recent interest in having a way to turn generally-available
kernel features off. Maybe we should add a good one so we can stop
bikeshedding and avoid
Andy Lutomirski l...@amacapital.net writes:
On Jul 27, 2014 5:06 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote:
There is recent interest in having a way to turn generally-available
kernel features off. Maybe we should add a good
[new thread because this sort of combines two threads]
There is recent interest in having a way to turn generally-available
kernel features off. Maybe we should add a good one so we can stop
bikeshedding and avoid proliferating dumb interfaces.
Things that might want to be turn-off-able
On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote:
There is recent interest in having a way to turn generally-available
kernel features off. Maybe we should add a good one so we can stop
bikeshedding and avoid proliferating dumb interfaces.
Things that might want to be
On Fri, Jul 25, 2014 at 1:15 PM, Dave Jones da...@redhat.com wrote:
On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote:
There is recent interest in having a way to turn generally-available
kernel features off. Maybe we should add a good one so we can stop
bikeshedding and
On Fri, 25 Jul 2014 11:30:48 -0700
Andy Lutomirski l...@amacapital.net wrote:
[new thread because this sort of combines two threads]
There is recent interest in having a way to turn generally-available
kernel features off. Maybe we should add a good one so we can stop
bikeshedding and
On Fri, Jul 25, 2014 at 2:35 PM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
On Fri, 25 Jul 2014 11:30:48 -0700
Andy Lutomirski l...@amacapital.net wrote:
[new thread because this sort of combines two threads]
There is recent interest in having a way to turn generally-available
On 07/25/2014 11:30 AM, Andy Lutomirski wrote:
- 32-bit GDT code segments [huge attack surface]
- 64-bit GDT code segments [probably pointless]
I presume you mean s/GDT/LDT/.
We already don't allow 64-bit LDT code segments. Also, it is unclear to
me how 32-bit LDT segments have a huge
On Fri, Jul 25, 2014 at 4:43 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/25/2014 11:30 AM, Andy Lutomirski wrote:
- 32-bit GDT code segments [huge attack surface]
- 64-bit GDT code segments [probably pointless]
I presume you mean s/GDT/LDT/.
We already don't allow 64-bit LDT code
14 matches
Mail list logo
