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 char *hash_type;
+ struct crypto_ahash *tfm =
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, delete the
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 char
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
jmor...@namei.org
--
To unsubscribe from this list:
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
+ */
+int
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
- 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 leosi...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx.c | 45
Replaces spinlock usage by a simple copy of the crypto context, avoiding
possible bottlenecks.
Signed-off-by: Leonidas Da Silva Barbosa leosi...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-cbc.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git
Replaces spinlock usage by a simple copy of the crypto context, avoiding
possible bottlenecks.
Signed-off-by: Leonidas Da Silva Barbosa leosi...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-ccm.c | 42 +++
1 files changed, 25 insertions(+), 17
Replaces spinlock usage by a simple copy of the crypto context, avoiding
possible bottlenecks.
Signed-off-by: Leonidas Da Silva Barbosa leosi...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-ctr.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git
Replaces spinlock usage by a simple copy of the crypto context, avoiding
possible bottlenecks.
Signed-off-by: Leonidas Da Silva Barbosa leosi...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-ecb.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git
Replaces spinlock usage by a simple copy of the crypto context, avoiding
possible bottlenecks.
Signed-off-by: Leonidas Da Silva Barbosa leosi...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-aes-gcm.c | 64 ++--
1 files changed, 35 insertions(+), 29
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
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) would
On Thu, Jul 24, 2014 at 8:18 AM, Henrique de Moraes Holschuh
h...@hmh.eng.br 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
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 ESOMETHING 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
On Thu, Jul 24, 2014 at 1:30 PM, Henrique de Moraes Holschuh
h...@hmh.eng.br 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 ESOMETHING to be able to deny access to GRND_RANDOM or
some
future extension ?
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
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 unsubscribe
19 matches
Mail list logo
