On Fri, Jan 25, 2019 at 02:26:27PM +, Horia Geanta wrote:
>
> Thus, it seems the problem lies in the fact that ahash_request structure
> defines
> the digest buffer as "u8 *result" - thus the memory area might not be DMAable.
Oh OK, I misunderstood. Anything that's in the form of a kernel
po
API is reworked following suggestions of Herbert Xu.
Previous akcipher .verify() just `decrypts' (using RSA encrypt which is
using public key) signature to uncover message hash, which was then
compared in upper level public_key_verify_signature() with the expected
hash value, which itself was neve
On 1/25/2019 3:48 PM, Herbert Xu wrote:
> On Fri, Jan 25, 2019 at 12:43:21PM +, Horia Geanta wrote:
>>
>> Herbert, is there something we could do to avoid this?
>
> Async crypto requests cannot be allocated off the stack. So
> whoever is doing this needs to stop.
>
IIUC, the crypto request i
On Tue, Jan 22, 2019 at 04:26:51PM +0100, Roland Hieber wrote:
>
> The cause is that the struct ahash_request *req is created as a
> stack-local variable up in the stack (presumably somewhere in the IMA
> implementation), then passed down into the CAAM driver, which tries to
> dma_single_map the re
On Fri, Jan 25, 2019 at 12:43:21PM +, Horia Geanta wrote:
>
> Herbert, is there something we could do to avoid this?
Async crypto requests cannot be allocated off the stack. So
whoever is doing this needs to stop.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
On Fri, Jan 25, 2019 at 02:18:09PM +0300, Vitaly Chikunov wrote:
>
> Well, if we allowed to reuse dst* fields why not just put digest over
> dst scatterlist? That would be much simpler.
Please see below.
> > The advantage of having it in one scatterlist is that for those
> > users that already
Am Freitag, 25. Januar 2019, 10:31:47 CET schrieb Milan Broz:
Hi Milan,
> The CRC32 is not a cryptographic hash algorithm,
> so the FIPS restrictions should not apply to it.
> (The CRC32C variant is already allowed.)
>
> This CRC32 variant is used for in dm-crypt legacy TrueCrypt
> IV implementa
On 1/22/2019 5:27 PM, Roland Hieber wrote:
> On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a
> warning is generated when accessing files on a filesystem for which IMA
> measurement is enabled:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at kernel/
On Fri, Jan 25, 2019 at 06:09:29PM +0800, Herbert Xu wrote:
> On Fri, Jan 18, 2019 at 11:58:46PM +0300, Vitaly Chikunov wrote:
> > Previous akcipher .verify() just `decrypts' (using RSA encrypt which is
> > using public key) signature to uncover message hash, which was then
> > compared in upper le
On Fri, Jan 18, 2019 at 10:48:00PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it
> sounds like it is requesting a weak key. Actually, it is requesting
> that weak keys be forbidden (for algorithms that have the notion
On Fri, Jan 18, 2019 at 06:26:42PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> The do_decrypt() function in util.c in the BCM crypto driver is never
> used, so remove it.
>
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/bcm/util.c | 40 ---
> d
On Fri, Jan 18, 2019 at 12:14:18AM +0100, Thomas Gleixner wrote:
> Precise and non-ambiguous license information is important. The recently
> added aegis header file has a SPDX license identifier, which is nice, but
> at the same time it has a contradictionary license boiler plate text.
>
> SPDX
On Fri, Jan 18, 2019 at 11:01:45AM -0800, David Tolnay wrote:
> From: David Tolnay
> Date: Mon, 7 Jan 2019 14:36:11 -0800
> Subject: [PATCH v2] virtio-rng: Avoid repeated init of completion
>
> The virtio-rng driver uses a completion called have_data to wait for a
> virtio read to be fulfilled by
On Fri, Jan 18, 2019 at 01:58:10PM +0800, Xiongfeng Wang wrote:
> The patchset introduce a helper to (un)register a array of crypto templates.
> The following patches use this helper to simplify the code. This is also
> a preparation for a coming patchset, which will register several crypto
> templ
On Thu, Jan 17, 2019 at 09:18:35AM -0800, Atul Gupta wrote:
> use is_eth_imm to determine immediate data than use sa_entry
> field which is common for tunnel and not per skb.
>
> Signed-off-by: Atul Gupta
> ---
> drivers/crypto/chelsio/chcr_core.h | 2 +-
> drivers/crypto/chelsio/chcr_ipsec.c
On Tue, Jan 15, 2019 at 03:43:10PM +0200, Gilad Ben-Yossef wrote:
> Assorted bug fixes and cleanups
>
> Gilad Ben-Yossef (3):
> crypto: ccree: unmap buffer before copying IV
> crypto: ccree: shared irq lines are not a bug
> crypto: ccree: don't copy zero size ciphertext
>
> Hadar Gat (4):
>
On Mon, Jan 14, 2019 at 01:52:24PM +, Nagadheeraj Rottela wrote:
> In process_response_list() invoke the callback handler after unmapping
> the DMA buffers. It ensures DMA data is synced form device to cpu
> before the client code access the data from callback handler.
>
> Fixes: c9613335bf4f
On Fri, Jan 18, 2019 at 11:58:46PM +0300, Vitaly Chikunov wrote:
> Previous akcipher .verify() just `decrypts' (using RSA encrypt which is
> using public key) signature to uncover message hash, which was then
> compared in upper level public_key_verify_signature() with the expected
> hash value, wh
On Fri, Jan 18, 2019 at 11:41:00PM +0300, Vitaly Chikunov wrote:
>
> a) RSA verify works differently (is it just disguised encrypt),
> b) We have separate wrapper module for it (pkcs1pad). Thus:
>
> Old API can not be removed. In other words, we can not replace
> .verify_rsa with .verify in these
The arm64 GHASH implementation either uses 8-bit or 64-bit
polynomial multiplication instructions, since the latter are
faster but not mandatory in the architecture.
Since that prevents us from testing both implementations on the
same system, let's expose both implementations to the crypto API,
wi
The arm64 CRC-T10DIF implementation either uses 8-bit or 64-bit
polynomial multiplication instructions, since the latter are
faster but not mandatory in the architecture.
Since that prevents us from testing both implementations on the
same system, let's expose both implementations to the crypto AP
Both the GHASH and the CRC-T10DIF SIMD routines are based on 64-bit
polynomial multiplication, but fall back to the slower 8-bit polynomial
instructions if the optional 64-bit PMULL instruction is not implemented.
This means we can only ever test one of the two on a single system,
which is unfortu
The CRC32 is not a cryptographic hash algorithm,
so the FIPS restrictions should not apply to it.
(The CRC32C variant is already allowed.)
This CRC32 variant is used for in dm-crypt legacy TrueCrypt
IV implementation (tcw); detected by cryptsetup test suite
failure in FIPS mode.
Signed-off-by: Mi
The SIMD routine ported from x86 used to have a special code path
for inputs < 16 bytes, which got lost somewhere along the way.
Instead, the current glue code aligns the input pointer to permit
the NEON routine to use special versions of the vld1 instructions
that assume 16 byte alignment, but thi
Fix the issues in both NEON implementations of the CRC-T10DIF routines,
that were reported by Eric's new testing code.
v2:
- keep alignment specifiers where possible (#1)
- clarify/fix commit log (#2)
- add fixes/cc-stable/etc tags
- add patches that drop the now unreacheable code (#3 - #4)
Ard B
Remove some code that is no longer called now that we make sure never
to invoke the SIMD routine with less that 16 bytes of input.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/crct10dif-ce-core.S | 13 -
1 file changed, 13 deletions(-)
diff --git a/arch/arm/crypto/crct10dif-ce-
Remove some code that is no longer called now that we make sure never
to invoke the SIMD routine with less than 16 bytes of input.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/crct10dif-ce-core.S | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/arm64/crypto/crct10dif-c
The SIMD routine ported from x86 used to have a special code path
for inputs < 16 bytes, which got lost somewhere along the way.
Instead, the current glue code aligns the input pointer to 16 bytes,
which is not really necessary on this architecture (although it
could be beneficial to performance to
28 matches
Mail list logo
