Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread Andi Kleen
Theodore Ts'o ty...@mit.edu writes: #undef __NR_syscalls -#define __NR_syscalls 277 +#define __NR_syscalls 278 You need to add the syscall to kernel/sys_ni.c too, otherwise it will be impossible to build without random device. -Andi -- a...@linux.intel.com -- Speaking for myself only --

Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread George Spelvin
One basic question... why limit this to /dev/random? If we're trying to avoid fd exhaustion attacks, wouldn't an atomically read a file into a buffer system call (that could be used on /dev/urandom, or /etc/hostname, or /proc/foo, or...) be more useful? E.g. ssize_t readat(int dirfd, char const

Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread George Spelvin
In the end people would just recall getentropy in a loop and fetch 256 bytes each time. I don't think the artificial limit does make any sense. I agree that this allows a potential misuse of the interface, but doesn't a warning in dmesg suffice? It makes their code not work, so they can are

Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread Theodore Ts'o
On Sun, Jul 20, 2014 at 08:50:06AM -0700, Andi Kleen wrote: Theodore Ts'o ty...@mit.edu writes: #undef __NR_syscalls -#define __NR_syscalls 277 +#define __NR_syscalls 278 You need to add the syscall to kernel/sys_ni.c too, otherwise it will be impossible to build without random

Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread Theodore Ts'o
On Sun, Jul 20, 2014 at 12:26:22PM -0400, George Spelvin wrote: One basic question... why limit this to /dev/random? If we're trying to avoid fd exhaustion attacks, wouldn't an atomically read a file into a buffer system call (that could be used on /dev/urandom, or /etc/hostname, or

Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread Andreas Schwab
Theodore Ts'o ty...@mit.edu writes: ERRORS EINVAL The buflen value was invalid. Also on unknown flags? Without that it would be impossible to probe for implemented flags. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3

Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread Theodore Ts'o
On Sun, Jul 20, 2014 at 07:27:42PM +0200, Andreas Schwab wrote: Theodore Ts'o ty...@mit.edu writes: ERRORS EINVAL The buflen value was invalid. Also on unknown flags? Without that it would be impossible to probe for implemented flags. We removed the cap on the buflen size

Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread Hannes Frederic Sowa
On So, 2014-07-20 at 13:03 -0400, George Spelvin wrote: In the end people would just recall getentropy in a loop and fetch 256 bytes each time. I don't think the artificial limit does make any sense. I agree that this allows a potential misuse of the interface, but doesn't a warning in

Re: [PATCH, RFC] random: introduce getrandom(2) system call

2014-07-20 Thread Dwayne Litzenberger
On Thu, Jul 17, 2014 at 01:01:16PM -0400, Theodore Ts'o wrote: The getrandom(2) system call is a superset of getentropy(2). When we add the support for this into glibc, it won't be terribly difficult nor annoying to drop the following in alongside the standard support needed for any new system

Re: [PATCH 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use

2014-07-20 Thread David Miller
From: Benoit Taine benoit.ta...@lip6.fr Date: Fri, 18 Jul 2014 17:26:47 +0200 We should prefer `const struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. This issue was reported by checkpatch. A simplified version of the semantic patch that makes