Hi Linus:
This push fixes these issues:
* Stack corruption in pseries hwrng driver.
* Missing DMA unmap in caam crypto driver.
* NUMA crash in qat crypto driver.
* Buggy mapping of zero-length associated data in qat crypto driver.
Please pull from
Hello,
could you please add this patch (already landed in 3.18-rc1) to
following stable kernels:
3.17.x, 3.14.x, 3.12.x, 3.4.x, 3.2.x?
The bugfix allows usage of crypto API socket on archs with PAGE_SIZE =
32 KiB (I have a typo in original changelog).
Some background for the bug (with
This adds support for the Imagination Technologies hash
accelerator that provides hardware acceleration for
SHA1 SHA224 SHA256 and MD5 Hashes.
This hardware is present in the upcoming Pistachio SoC.
James Hartley (2):
crypto: Add Imagination Technologies hw hash accelerator
Documentation:
This adds support for the Imagination Technologies hash
accelerator that provides hardware acceleration for
SHA1 SHA224 SHA256 and MD5 Hashes.
Signed-off-by: James Hartley james.hart...@imgtec.com
---
MAINTAINERS |5 +
drivers/crypto/Kconfig| 13 +
drivers/crypto/Makefile
Signed-off-by: James Hartley james.hart...@imgtec.com
---
.../devicetree/bindings/crypto/img-hash.txt| 28
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/img-hash.txt
diff --git
On Sat, Nov 08, 2014 at 01:32:30AM +0100, Stephan Mueller wrote:
Hi Herbert,
I am in the process to extend algif_skcipher to support AEAD ciphers as well.
The code already works but I want to run final tests before releasing it.
In the course of the development I stumbled over the
On Sun, Nov 09, 2014 at 11:33:52PM +0100, Stephan Mueller wrote:
while working on the AF_ALG interface, I saw no active zeroizations of memory
that may hold sensitive data that is maintained outside the kernel crypto API
cipher handles. I think the following memory segments fall under that
On Tue, Nov 04, 2014 at 03:08:09AM +0100, Stephan Mueller wrote:
The kernel module drbg.ko is currently not loaded automatically when a
DRBG is requested by a consumer. This is due to missing MODULE_ALIAS
flags for each of the implemented DRBG types.
This patch adds aliases for each of the
On Thu, Nov 06, 2014 at 02:27:35PM +0100, Ulf Hansson wrote:
The system PM functions were unused when CONFIG_PM is unset. Let's move
them inside CONFIG_PM_SLEEP to silence the compiler warning.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Both patches applied.
--
Email: Herbert Xu
Hello James,
On 10.11.2014 14:10, James Hartley wrote:
This adds support for the Imagination Technologies hash
accelerator that provides hardware acceleration for
SHA1 SHA224 SHA256 and MD5 Hashes.
Signed-off-by: James Hartley james.hart...@imgtec.com
---
[snip]
diff --git
Hi James,
On Mon, Nov 10, 2014 at 4:10 AM, James Hartley james.hart...@imgtec.com wrote:
Signed-off-by: James Hartley james.hart...@imgtec.com
A brief commit message describing the hardware and where it's found
would be nice.
diff --git a/Documentation/devicetree/bindings/crypto/img-hash.txt
Hi Herbert,
Is the PCOMPRESS algorithm supposed to support asynchronous
implementations? In other words, are callers expected to handle the
-EINPROGRESS or -EAGAIN return codes that can be returned by an
asynchronous implementation?
Or is it assumed that if the CRYPTO_ALG_ASYNC flag is not set
On Mon, Nov 10, 2014 at 11:50:36AM +0100, Ondrej Kozina wrote:
Hello,
could you please add this patch (already landed in 3.18-rc1) to following
stable kernels:
3.17.x, 3.14.x, 3.12.x, 3.4.x, 3.2.x?
The bugfix allows usage of crypto API socket on archs with PAGE_SIZE = 32
KiB (I have a
Am Montag, 10. November 2014, 22:05:18 schrieb Herbert Xu:
Hi Herbert,
On Sun, Nov 09, 2014 at 11:33:52PM +0100, Stephan Mueller wrote:
while working on the AF_ALG interface, I saw no active zeroizations of
memory that may hold sensitive data that is maintained outside the kernel
crypto
On Tue, Nov 11, 2014 at 03:06:32AM +0100, Stephan Mueller wrote:
Am Montag, 10. November 2014, 22:05:18 schrieb Herbert Xu:
Hi Herbert,
On Sun, Nov 09, 2014 at 11:33:52PM +0100, Stephan Mueller wrote:
while working on the AF_ALG interface, I saw no active zeroizations of
memory that
On Sun, Nov 9, 2014 at 5:33 PM, Stephan Mueller smuel...@chronox.de wrote:
while working on the AF_ALG interface, I saw no active zeroizations of memory
that may hold sensitive data that is maintained outside the kernel crypto API
cipher handles. ...
I think I found the location for the
Am Montag, 10. November 2014, 21:55:43 schrieb Sandy Harris:
Hi Sandy, Herbert,
On Sun, Nov 9, 2014 at 5:33 PM, Stephan Mueller smuel...@chronox.de wrote:
while working on the AF_ALG interface, I saw no active zeroizations of
memory that may hold sensitive data that is maintained outside
On Tue, Nov 11, 2014 at 05:16:54AM +0100, Stephan Mueller wrote:
Shall I now still use memset(0) or prepare a patch that does not yet compile
by using memzero_explicit?
Just send the patch with the memzer_explicit and I'll make sure
that I pull the requisite changes in before I apply your
Zeroize the buffer holding the IV used for the completed
cipher operation before the buffer is released by the
skcipher AF_ALG interface handler.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/algif_skcipher.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi Herbert,
as discussed, these patches use the memzero_explicit function that is
yet to be integrated into the cryptodev-2.6 tree.
Stephan Mueller (2):
crypto: AF_ALG - zeroize message digest buffer
crypto: AF_ALG - zeroize IV buffer
crypto/algif_hash.c | 2 ++
crypto/algif_skcipher.c
20 matches
Mail list logo
