Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread H. Peter Anvin
On 07/24/2014 01:54 PM, Andy Lutomirski wrote: > > Or that someone writes userspace code that gets -EPERM/-EACCESS on > getrandom with GRND_RANDOM and falls back to something worse than > getrandom w/o GRND_RANDOM. > -ENXIO? -hpa -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread Andy Lutomirski
On Thu, Jul 24, 2014 at 4:24 PM, Theodore Ts'o wrote: > On Thu, Jul 24, 2014 at 05:30:19PM -0300, Henrique de Moraes Holschuh wrote: >> > I wouldn't add the error to the man page until we actually modify the >> > kernel to add such a restriction. >> >> By then, it might be too late. It would be r

Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread Theodore Ts'o
On Thu, Jul 24, 2014 at 05:30:19PM -0300, Henrique de Moraes Holschuh wrote: > > I wouldn't add the error to the man page until we actually modify the > > kernel to add such a restriction. > > By then, it might be too late. It would be really sad to find ourselves > forced to return ENOSYS to get

Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread Andy Lutomirski
On Thu, Jul 24, 2014 at 1:30 PM, Henrique de Moraes Holschuh wrote: > On Thu, 24 Jul 2014, Theodore Ts'o wrote: >> On Thu, Jul 24, 2014 at 08:21:38AM -0700, Andy Lutomirski wrote: >> > > Should we add E to be able to deny access to GRND_RANDOM or >> > > some >> > > future extension ? >> > >> > Th

Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread Henrique de Moraes Holschuh
On Thu, 24 Jul 2014, Theodore Ts'o wrote: > On Thu, Jul 24, 2014 at 08:21:38AM -0700, Andy Lutomirski wrote: > > > Should we add E to be able to deny access to GRND_RANDOM or > > > some > > > future extension ? > > > > This might actually be needed sooner rather than later. There are > > program

Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread Theodore Ts'o
On Thu, Jul 24, 2014 at 08:21:38AM -0700, Andy Lutomirski wrote: > > > > Should we add E 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/r

Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread Andy Lutomirski
On Thu, Jul 24, 2014 at 8:18 AM, Henrique de Moraes Holschuh wrote: > On Thu, 24 Jul 2014, Theodore Ts'o wrote: >> ERRORS >> EINVAL An invalid flag was passed to getrandom(2) >> >> EFAULT buf is outside the accessible address space. >> >> EAGAIN The req

Re: [PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread Henrique de Moraes Holschuh
On Thu, 24 Jul 2014, Theodore Ts'o wrote: > ERRORS > EINVAL An invalid flag was passed to getrandom(2) > > EFAULT buf is outside the accessible address space. > > EAGAIN The requested entropy was not available, and > getentropy(2)

[PATCH -v5] random: introduce getrandom(2) system call

2014-07-24 Thread Theodore Ts'o
The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD. The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descr

[PATCH 8/8] Replacing spinlocks by nx_copy_ctx on NX-SHA256 and NX-SHA512

2014-07-24 Thread Leonidas Da Silva Barbosa
Replaces spinlock usage by a simple copy of the crypto context, avoiding possible bottlenecks. Signed-off-by: Leonidas Da Silva Barbosa --- drivers/crypto/nx/nx-sha256.c | 70 + drivers/crypto/nx/nx-sha512.c | 70 +--

[PATCH 7/8] Replacing spinlocks by nx_copy_ctx on NX-AES-XCBC

2014-07-24 Thread Leonidas Da Silva Barbosa
Replaces spinlock usage by a simple copy of the crypto context, avoiding possible bottlenecks. Signed-off-by: Leonidas Da Silva Barbosa --- drivers/crypto/nx/nx-aes-xcbc.c | 51 ++ 1 files changed, 29 insertions(+), 22 deletions(-) diff --git a/drivers/cryp

[PATCH 6/8] Replacing spinlocks by nx_copy_ctx on NX-AES-GCM

2014-07-24 Thread Leonidas Da Silva Barbosa
Replaces spinlock usage by a simple copy of the crypto context, avoiding possible bottlenecks. Signed-off-by: Leonidas Da Silva Barbosa --- drivers/crypto/nx/nx-aes-gcm.c | 64 ++-- 1 files changed, 35 insertions(+), 29 deletions(-) diff --git a/drivers/cry

[PATCH 5/8] Replacing spinlocks by nx_copy_ctx on NX-AES-ECB

2014-07-24 Thread Leonidas Da Silva Barbosa
Replaces spinlock usage by a simple copy of the crypto context, avoiding possible bottlenecks. Signed-off-by: Leonidas Da Silva Barbosa --- drivers/crypto/nx/nx-aes-ecb.c | 20 1 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/nx/nx-aes-ecb.c b

[PATCH 4/8] Replacing spinlocks by nx_copy_ctx on NX-AES-CTR

2014-07-24 Thread Leonidas Da Silva Barbosa
Replaces spinlock usage by a simple copy of the crypto context, avoiding possible bottlenecks. Signed-off-by: Leonidas Da Silva Barbosa --- drivers/crypto/nx/nx-aes-ctr.c | 20 1 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/nx/nx-aes-ctr.c b

[PATCH 3/8] Replacing spinlocks by nx_copy_ctx on NX-AES-CCM

2014-07-24 Thread Leonidas Da Silva Barbosa
Replaces spinlock usage by a simple copy of the crypto context, avoiding possible bottlenecks. Signed-off-by: Leonidas Da Silva Barbosa --- drivers/crypto/nx/nx-aes-ccm.c | 42 +++ 1 files changed, 25 insertions(+), 17 deletions(-) diff --git a/drivers/cryp

[PATCH 2/8] Replacing spinlocks by nx_copy_ctx on NX-AES-CBC

2014-07-24 Thread Leonidas Da Silva Barbosa
Replaces spinlock usage by a simple copy of the crypto context, avoiding possible bottlenecks. Signed-off-by: Leonidas Da Silva Barbosa --- drivers/crypto/nx/nx-aes-cbc.c | 20 1 files changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/nx/nx-aes-cbc.c b

[PATCH 1/8] Adding nx_copy_ctx and kmemcache to handle with crypto context

2014-07-24 Thread Leonidas Da Silva Barbosa
- This patch adds kmemcache to nx_driver in replace the use of spinlocks in nx. - Adds a copy function that handles with the current context as a copy of the context in crypto API. Signed-off-by: Leonidas Da Silva Barbosa --- drivers/crypto/nx/nx.c | 45

[PATCH 0/8] NX crypto driver reestructure

2014-07-24 Thread Leonidas Da Silva Barbosa
This set of patches deals with the reescruture of NX driver replacing the use of spinlocks, that assure crypto context concurrency, by a copy of crypto ctx to another region of memory in order to be used by the current algorithm. As this region of memory tends to be used constantly also was added

Re: [PATCH v4 3/3] crypto: Add Allwinner Security System crypto accelerator

2014-07-24 Thread Herbert Xu
On Thu, Jul 24, 2014 at 01:04:55PM +0200, Corentin LABBE wrote: > Le 24/07/2014 08:00, Herbert Xu a écrit : > > On Sat, Jul 12, 2014 at 02:59:13PM +0200, LABBE Corentin wrote: > >> > >> +/* sunxi_hash_init: initialize request context > >> + * Activate the SS, and configure it for MD5 or SHA1 > >> +

Re: [GIT PULL] Keyrings and asymmetric keys patches for 3.17

2014-07-24 Thread James Morris
On Tue, 22 Jul 2014, David Howells wrote: > I have a number of sets of patches for you to pull. I've git-merged them > together into a single branch (keys-next) as there are some conflicts and > tagged the end. Pulled, thanks. -- James Morris -- To unsubscribe from this list: send the line "

Re: [PATCH v4 3/3] crypto: Add Allwinner Security System crypto accelerator

2014-07-24 Thread Corentin LABBE
Le 24/07/2014 08:00, Herbert Xu a écrit : > On Sat, Jul 12, 2014 at 02:59:13PM +0200, LABBE Corentin wrote: >> >> +/* sunxi_hash_init: initialize request context >> + * Activate the SS, and configure it for MD5 or SHA1 >> + */ >> +int sunxi_hash_init(struct ahash_request *areq) >> +{ >> +const

Re: [PATCH] crypto: ccp - Remove "select OF" from Kconfig

2014-07-24 Thread Herbert Xu
On Wed, Jul 23, 2014 at 09:45:19AM -0500, Tom Lendacky wrote: > The addition of the "select OF if ARM64" has led to a Kconfig > recursive dependency error when "make ARCH=sh rsk7269_defconfig" > was run. Since OF is selected by ARM64 and the of_property_read_bool > is defined no matter what, delet