On Wed, Sep 20, 2017 at 08:31:40PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
>
> Signed-off-by: Corentin Labbe
Patch applied. Thanks.
--
Email: Herb
On Wed, Sep 20, 2017 at 08:47:26PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
>
> Signed-off-by: Corentin Labbe
Patch applied. Thanks.
--
Email: Herb
On Wed, Sep 20, 2017 at 08:42:48PM +0200, Corentin Labbe wrote:
> The usage of of_device_get_match_data reduce the code size a bit.
> Furthermore, it prevents an improbable dereference when
> of_match_device() return NULL.
>
> Signed-off-by: Corentin Labbe
Patch applied. Thanks.
--
Email: Herb
On Thu, Sep 14, 2017 at 07:02:19PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable len is set to zero, never read and then later updated
> to p - name, so clearly the zero'ing of len is redundant and
> can be removed.
>
> Detected by clang scan-build:
> " warning: Value stored t
Allen Pais wrote:
> Signed-off-by: Allen Pais
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, Sep 12, 2017 at 11:35:38AM +0200, Arnd Bergmann wrote:
> The error handling in stm32_hash_irq_thread passes
> uninitialized data into stm32_hash_finish_req, as gcc
> points out:
>
> drivers/crypto/stm32/stm32-hash.c: In function 'stm32_hash_irq_thread':
> drivers/crypto/stm32/stm32-hash.c:
On Tue, Sep 12, 2017 at 11:35:39AM +0200, Arnd Bergmann wrote:
> gcc warns that the length for the extra unaligned data in the hash
> function may be used unaligned. In theory this could happen if
> we pass a zero-length sg_list, or if sg_is_last() was never true:
>
> In file included from drivers
On Wed, Sep 06, 2017 at 10:41:21PM -0400, Mikulas Patocka wrote:
> In 32-bit mode, the x86 architecture can hold full 32-bit pointers.
> Therefore, the code that copies the current address to the %ecx register
> and uses %ecx-relative addressing is useless, we could just use absolute
> addressing.
On Tue, Sep 26, 2017 at 08:17:44AM +0200, Christophe JAILLET wrote:
> All error handling paths 'goto err_drop_spawn' except this one.
> In order to avoid some resources leak, we should do it as well here.
>
> Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
> Signed-off-by: Christophe JAI
On Tue, Sep 05, 2017 at 05:01:51PM -0500, Gary R Hook wrote:
> From: amd
>
> Clean up the mapped pages and the unmap object once we are done with
> it. This enables the final clean-up of the object once the transfer
> is complete.
>
> Signed-off-by: Gary R Hook
Patch applied. Thanks.
--
Emai
On Tue, Sep 05, 2017 at 05:08:14PM -0500, Gary R Hook wrote:
> From: amd
>
> Use the provided mechanism in dmaengine.h to invoke the
> completion callback.
>
> Signed-off-by: Gary R Hook
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: htt
On Fri, Sep 08, 2017 at 08:57:08PM +0200, Mathias Krause wrote:
> Hi Steffen, Herbert,
>
> this series solves multiple issues of padata I ran into while trying to
> make use of pcrypt for IPsec.
>
> The first issue is that the reorder timer callback may run on a CPU that
> isn't part of the paral
Mathieu Malaterre wrote:
> This makes it simplier for driver author to not provide the seed() function
> in case of a pseudo RNG where the seed operation is a no-op.
>
> Document that the seed() function pointer is optional in header.
>
> Signed-off-by: Mathieu Malaterre
> ---
> The PRNG as fou
On Sat, Oct 07, 2017 at 05:21:38AM +0200, Stephan Müller wrote:
>
> The bug happens with the following invocation sequence:
>
> setsockopt(3, SOL_ALG, 5, NULL, 1) = -1 EBUSY (Device or resource busy)
> sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0,
> msg_control=[{cmsg
Am Samstag, 7. Oktober 2017, 05:07:52 CEST schrieb Herbert Xu:
Hi Herbert,
> On Sat, Oct 07, 2017 at 04:53:46AM +0200, Stephan Müller wrote:
> > I use authenc(hmac(sha256),cbc(aes)) which in turn uses cbc-aes-aesni on
> > my
> > system.
>
> So where exactly is it crashing in cbc-aes-aesni? AFAIC
On Sat, Oct 07, 2017 at 04:53:46AM +0200, Stephan Müller wrote:
>
> I use authenc(hmac(sha256),cbc(aes)) which in turn uses cbc-aes-aesni on my
> system.
So where exactly is it crashing in cbc-aes-aesni? AFAICS it should
handle the zero case just fine. Or is it hmac that's crashing as
your other
On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
>
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 5e92bd2..3b3c154 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -39,6 +39,20 @@ struct algif_hash_tfm {
> bool has_key;
> };
>
> +/* Pre
Am Samstag, 7. Oktober 2017, 04:51:17 CEST schrieb Herbert Xu:
Hi Herbert,
>
> No I'm talking about the underlysing skcipher. authenc is an
> aead, and it is legal to make a zero skcipher call. The underlying
> skcipher should make sure that it works.
>
> So which underlying skcipher is barfi
On Sat, Oct 07, 2017 at 04:49:10AM +0200, Stephan Müller wrote:
> Am Samstag, 7. Oktober 2017, 04:46:35 CEST schrieb Herbert Xu:
>
> Hi Herbert,
>
> > Hmm this just papers over bugs in the underlying code. Which
> > algorithm is causing the crash with a zero input? They're supposed
> > to handle
Am Samstag, 7. Oktober 2017, 04:46:35 CEST schrieb Herbert Xu:
Hi Herbert,
> Hmm this just papers over bugs in the underlying code. Which
> algorithm is causing the crash with a zero input? They're supposed
> to handle this case.
The bug happens with authenc. It is surely possible to modify aut
On Sun, Sep 24, 2017 at 08:24:58AM +0200, Stephan Müller wrote:
> The encryption / decryption operation is a noop in case the caller
> provides zero input data. As this noop is a "valid" operation, the API
> calls will return no error, but simply skip any processing.
>
> This fixes a kernel crash
On Sun, Sep 24, 2017 at 08:25:17AM +0200, Stephan Müller wrote:
> In case the caller provides an SG with zero data, prevent a kmap of the
> page pointed to by the SG. In this case, it is possible that the page
> does not exist.
>
> This fixes a crash in authenc() when the plaintext is zero and thu
The SEV_FACTORY_RESET command can be used by the platform owner to
reset the non-volatile SEV related data. The command is defined in
SEV spec section 5.4
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
C
The SEV_PEK_GEN command is used to generate a new Platform Endorsement
Key (PEK). The command is defined in SEV spec section 5.6.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
C
AMD's new Secure Encrypted Virtualization (SEV) feature allows the
memory contents of virtual machines to be transparently encrypted with a
key unique to the VM. The programming and management of the encryption
keys are handled by the AMD Secure Processor (AMD-SP) which exposes the
commands for the
The SEV_PLATFORM_STATUS command can be used by the platform owner to
get the current status of the platform. The command is defined in
SEV spec section 5.5.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
The SEV_PDH_CERT_EXPORT command can be used to export the PDH and its
certificate chain. The command is defined in SEV spec section 5.10.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kern
The SEV_PEK_CERT_IMPORT command can be used to import the signed PEK
certificate. The command is defined in SEV spec section 5.8.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
C
The SEV_PDH_GEN command is used to re-generate the Platform
Diffie-Hellman (PDH) key. The command is defined in SEV spec section
5.9.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.o
The SEV_PEK_CSR command can be used to generate a PEK certificate
signing request. The command is defined in SEV spec section 5.7.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
Add a include file which defines the ioctl and command id used for
issuing SEV platform management specific commands.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: linux-ker
The Platform Security Processor (PSP) is part of the AMD Secure
Processor (AMD-SP) functionality. The PSP is a dedicated processor
that provides support for key management commands in Secure Encrypted
Virtualization (SEV) mode, along with software-based Trusted Execution
Environment (TEE) to enable
On 10/6/17 1:49 PM, Borislav Petkov wrote:
...
>> +
>> +static unsigned int sev_poll;
>> +module_param(sev_poll, uint, 0444);
>> +MODULE_PARM_DESC(sev_poll, "Poll for sev command completion - any non-zero
>> value");
> What is that used for? Some debugging leftover probably? If not, add a
> comm
On Wed, Oct 04, 2017 at 08:13:53AM -0500, Brijesh Singh wrote:
> AMDs new Secure Encrypted Virtualization (SEV) feature allows the memory
> contents of a virtual machines to be transparently encrypted with a key
> unique to the guest VM. The programming and management of the encryption
> keys are h
On Wed, Oct 04, 2017 at 06:38:11PM +0200, Kamil Konieczny wrote:
> Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW.
> It uses the crypto framework asynchronous hash api.
> It is based on omap-sham.c driver.
> S5P has some HW differencies and is not implemented.
>
> Modifications in
On Fri, Oct 06, 2017 at 04:43:09PM +0200, Joerg Roedel wrote:
> On Tue, Oct 03, 2017 at 07:05:17PM +0100, Robin Murphy wrote:
> > Now, there are indeed plenty of drivers and subsystems which do work on
> > lists of explicitly single pages - anything doing some variant of
> > "addr = kmap_atomic(sg_
Certain cipher modes like CTS expect the IV (req->info) of
ablkcipher_request (or equivalently req->iv of skcipher_request) to
contain the last ciphertext block when the {en,de}crypt operation is done.
Fix this issue for the Atmel AES hardware engine. The tcrypt test
case for cts(cbc(aes)) is now
On Tue, Oct 03, 2017 at 07:05:17PM +0100, Robin Murphy wrote:
> Now, there are indeed plenty of drivers and subsystems which do work on
> lists of explicitly single pages - anything doing some variant of
> "addr = kmap_atomic(sg_page(sg)) + sg->offset;" is easy to spot - but I
> don't think DMA API
Hello, please did you receive my previous email to you?
This serie fixes and improves the talitos crypto driver.
First 6 patchs are fixes of failures reported by the new tests in the
kernel crypto test manager.
The 8 following patches are cleanups and simplifications.
The last 4 ones are performance improvement. The main improvement is
in the one bef
AEAD tests fail when destination SG list has more than 1 element.
[2.058752] alg: aead: Test 1 failed on encryption for
authenc-hmac-sha1-cbc-aes-talitos
[2.066965] : 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
0010: c0 43 ff 74 c0 43 ff e0 de 83 d1 20 de 84 8e 54
0020
sg_link_tbl_len shall be used instead of cryptlen, otherwise
SECs which perform HW CICV verification will fail.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
Crypto manager test report the following failures:
[3.061081] alg: skcipher: setkey failed on test 5 for ecb-des-talitos:
flags=100
[3.069342] alg: skcipher-ddst: setkey failed on test 5 for ecb-des-talitos:
flags=100
[3.077754] alg: skcipher-ddst: setkey failed on test 5 for ecb-des-
sha224 AEAD test fails with:
[2.803125] talitos ff02.crypto: DEUISR 0x_
[2.808743] talitos ff02.crypto: MDEUISR 0x8010_
[2.814678] talitos ff02.crypto: DESCBUF 0x20731f21_0018
[2.820616] talitos ff02.crypto: DESCBUF 0x0628d64c_001
On SEC2, when using the old descriptors type (hmac snoop no afeu)
for doing IPsec, the CICV out pointeur points out of the allocated
memory.
[2.502554]
=
[2.510740] BUG dma-kmalloc-256 (Not tainted): Redzone overw
This patch zeroize the descriptor at allocation using memset().
This has two advantages:
- It reduces the number of places where data has to be set to 0
- It avoids reading memory and loading the cache with data that
will be entirely replaced.
Signed-off-by: Christophe Leroy
---
drivers/crypto/t
ctr-aes-talitos test fails as follows on SEC2
[0.837427] alg: skcipher: Test 1 failed (invalid result) on encryption for
ctr-aes-talitos
[0.845763] : 16 36 d5 ee 34 f8 06 25 d7 7f 8e 56 ca 88 43 45
[0.852345] 0010: f9 3f f7 17 2a b2 12 23 30 43 09 15 82 dd e1 97
[0.858
talitos_handle_buggy_hash() and talitos_sg_map() are only used
locally, make them static
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 266e7e626e12..dd
Replace kmalloc() by devm_kmalloc()
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dd6b1fc90020..2a53d0f2a869 100644
--- a/
The number of channels is known from the beginning, no need to
test it everytime.
This patch defines two additional done functions handling only channel 0.
Then the probe registers the correct one based on the number of channels.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 27
Use of_property_read_u32() to simplify DT read
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 2a53d0f2a869..f139a0cef2e2 100644
--- a
Do (desc->hdr & DESC_HDR_TYPE_IPSEC_ESP) only once.
Limit number of if/else paths
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 42 --
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypt
dma_map_single() is an heavy operation which doesn't need to
be done at each request as the key doesn't change.
Instead of DMA mapping the key at every request, this patch maps it
once in setkey()
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 56
At every request, we map and unmap the same hash hw_context.
This patch moves the dma mapping/unmapping in functions ahash_init()
and ahash_import().
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 80 ++--
1 file changed, 57 insertions
to_talitos_ptr() and to_talitos_ptr_len() are always called together
in order to fully set a ptr, so lets merge them into a single
helper.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 56 ++--
1 file changed, 21 insertions(+), 35 dele
This patch avoids copy of buffered data to hash from bufnext to buf
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 5c
SEC1 doesn't support S/G in descriptors so for hash operations,
the CPU has to build a buffer containing the buffered block and
the incoming data. This generates a lot of memory copies which
represents more than 50% of CPU time of a md5sum operation as
shown below with a 'perf record'.
|--86.24%--
Use devm_ioremap()
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index f139a0cef2e2..83b2a70a1ba7 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/cry
OK, I will send an initial version without the AEAD part.
On 05/10/17 05:39, Herbert Xu wrote:
> On Tue, Oct 03, 2017 at 07:48:08AM +, Fabien DESSENNE wrote:
>> It looks like there is no more activity around this "crypto_engine
>> interface clean up" task.
>> This unfortunately has been block
59 matches
Mail list logo
