[+Cc linux-crypto]
Hi Yael,
On Sun, Mar 25, 2018 at 07:41:30PM +0100, Yael Chemla wrote:
> Allow parallel processing of bio blocks by moving to async. completion
> handling. This allows for better resource utilization of both HW and
> software based hash tfm and therefore better performance in
+CC linux-crypto@vger.kernel.org
No functional change, though.
2018-03-23 22:04 GMT+09:00 Masahiro Yamada :
> Clean up these patterns from the top Makefile to omit 'clean-files'
> in each Makefile.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Makefile| 1 +
> crypto/Make
+CC linux-crypto@vger.kernel.org
No functional change, though.
(I fixed up the subject.)
2018-03-23 22:04 GMT+09:00 Masahiro Yamada :
> Our convention is to distinguish file types by suffixes with a period
> as a separator.
>
> *-asn1.[ch] is a different pattern from other generated sources suc
+CC linux-crypto@vger.kernel.org
No functional change, though.
2018-03-23 22:04 GMT+09:00 Masahiro Yamada :
> These are common patterns where source files are parsed by the
> asn1_compiler.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> .gitignore | 5 +
> crypt
On the quest to remove all VLAs from the kernel[1], this avoids VLAs
by just using the maximum allocation size (4 bytes) for stack arrays.
All the VLAs in ecc were either 3 or 4 bytes (or a multiple), so just
make it 4 bytes all the time. Initialization routines are adjusted to
check that ndigits d
On Fri, Mar 16, 2018 at 8:56 AM, Herbert Xu wrote:
> On Thu, Mar 08, 2018 at 01:57:02PM -0800, Kees Cook wrote:
>> On the quest to remove all VLAs from the kernel[1], this switches to
>> a pair of kmalloc regions instead of using the stack. This also moves
>> the get_random_bytes() after all alloc
On 26/03/18 01:50 PM, Arnd Bergmann wrote:
> I wouldn't expect it to matter: the byte swap is almost always much
> cheaper compared to the actual bus access for the MMIO, and I
> would also guess that modern compilers can eliminate the double
> byte swap on architectures where writel() is an inli
On Mon, Mar 26, 2018 at 6:21 PM, Logan Gunthorpe wrote:
>
>
> On 26/03/18 04:53 AM, Arnd Bergmann wrote:
>> On most architectures, this is not important:
>> - For x86, the stores are aways atomic and no additional barriers
>> are needed, so the two are the same
>> - For ARM (both 32 and 64-bit),
On 26/03/18 04:53 AM, Arnd Bergmann wrote:
> On most architectures, this is not important:
> - For x86, the stores are aways atomic and no additional barriers
> are needed, so the two are the same
> - For ARM (both 32 and 64-bit), powerpc and many others, we don't
> use the generic iowrite()
On 03/12/2018 07:07 PM, Tudor Ambarus wrote:
Would you consider using ECDSA in the kernel module signing facility?
Any feedback is good. I can invest some time to make this happen, if
needed.
When compared with RSA, ECDSA has shorter keys, the key generation
process is faster, the sign ope
On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote:
> With the introduction of another IMA signature type (modsig), some places
> will need to check for both of them. It is cleaner to do that if there's a
> helper function to tell whether an xattr_value represents an IMA
> signature.
I
On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote:
> This patch actually implements the appraise_type=imasig|modsig option,
> allowing IMA to read and verify modsig signatures.
>
> In case both are present in the same file, IMA will first check whether the
> key used by the xattr sign
On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote:
> Define new "d-sig" template field which holds the digest that is expected
> to match the one contained in the modsig.
>
> Also add modsig support to the "sig" template field, allowing the the
> contents of the modsig to be included
Remove useless assignment of ret to -ENOMEM in rsa_verify.
Remove useless initialization of ret to zero at declaration in
rsa_enc/dec/sign/verify.
Benefit of the power of undefined values and set ret in branches in
rsa_enc/dec/sign.
Reported-by: Benjamin Bales
Signed-off-by: Tudor Ambarus
---
On Wed, Mar 21, 2018 at 5:37 PM, Logan Gunthorpe wrote:
> The semantics of the iowriteXXbe() functions are to write a
> value in CPU endianess to an IO register that is known by the
> caller to be in Big Endian. The mmio_writeXXbe() macro, which
> is called by iowriteXXbe(), should therefore use c
On 3/23/2018 12:42 PM, Tudor Ambarus wrote:
> In caam's aead_setkey we save pointers to the authenc keys in a
> local variable of type struct crypto_authenc_keys and we don't
> zeroize it after use. Fix this and don't leak pointers to the
> authenc keys.
>
> Signed-off-by: Tudor Ambarus
Reviewed-
On 3/23/2018 12:42 PM, Tudor Ambarus wrote:
> In caam/qi's aead_setkey we save pointers to the authenc keys in
> a local variable of type struct crypto_authenc_keys and we don't
> zeroize it after use. Fix this and don't leak pointers to the
> authenc keys.
>
> Signed-off-by: Tudor Ambarus
Review
Hi Benjamin,
Thanks for the nice present and good testing!
I hope to grab a chance to test this shiny new algorithm but is busy this week.
Hopefully, I will get that soon and feedback to you asap.
Thanks.
On Mon, Mar 26, 2018 at 10:31:40AM +0200, Benjamin Warnke wrote:
> This patch series adds
Most compression algorithms published by the crypto api are supporting
multiple different compression levels. The crypto api currently just
calls these algorithms with their default compression level.
This patch enables the caller to specify the compression level.
Signed-off-by: Benjamin Warnke <
This patch adds zBeWalgo to the crypto api so that zBeWalgo can be used by
zram.
Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
crypto/Kconfig| 12
crypto/Makefile | 1 +
crypto/testmgr.c | 10 +++
crypto/testmgr.h
Up to Version 3 of this patch the decompressor of zbewalgo did not verify
that there is no overflow in the output buffer. Now zbewalgo includes a
safe decompressor which does check for buffer overflows and heap-error.
ZBewalgo and other Algorithms like lz4 include an unsafe decompressor version,
wh
This patch series adds a new compression algorithm to the kernel and to
the crypto api.
Changes since v5:
- Fixed compile-error due to variable definitions inside #ifdef
CONFIG_ZRAM_WRITEBACK
Changes since v4:
- Fix mismatching function-prototypes
- Fix mismatching License errors
- Add static to
zBeWalgo is a completely new algorithm - Currently it is not published
somewhere else right now, googleing it would not show up any results. The
following section describes how the algorithm works.
zBeWalgo itself is a container compression algorithm, which can execute
multiple different compressi
The data-format of zBeWalgo, and some other algorithms is unstable. To
identify such unstable algorithms this patch adds a new flag to the
crypto-api.
Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
crypto/zbewalgo.c | 2 +-
include/linux/crypto.h | 6 ++
2 files
Small cleanup and add support for CryptoCell hardware keys.
Gilad Ben-Yossef (2):
crypto: ccree: remove unused enums
crypto: ccree: enable support for hardware keys
crypto/testmgr.c| 43
drivers/crypto/ccree/cc_cipher.c| 348 -
Remove enums definitions unused in the driver code.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccree/cc_hw_queue_defs.h | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/crypto/ccree/cc_hw_queue_defs.h
b/drivers/crypto/ccree/cc_hw_
Enable CryptoCell support for hardware keys.
Hardware keys are regular AES keys loaded into CryptoCell internal memory
via firmware, often from secure boot ROM or hardware fuses at boot time.
As such, they can be used for enc/dec purposes like any other key but
cannot (read: extremely hard to) be
27 matches
Mail list logo
