On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> If the pcrypt template is used multiple times in an algorithm, then a
> deadlock occurs because all pcrypt instances share the same
> padata_instance, which completes requests in the order submitted. That
> is
The buffer rctx->ext contains potentially sensitive data and should
be freed with kzfree.
Cc:
Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
Reported-by: Dan Carpenter
Signed-off-by: Herbert Xu
diff --git a/crypto/lrw.c b/crypto/lrw.c
index a09cdaa..954a706 100644
--- a/crypto/lrw.c
Hi Maninder,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6]
[cannot apply to next-20180322]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Maninder,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6]
[cannot apply to next-20180322]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote:
> IMA will need to access the digest of the PKCS7 message (as calculated by
> the kernel) before the signature is verified, so introduce
> pkcs7_get_digest() for that purpose.
>
> Also, modify pkcs7_digest() to detect when the digest
Hi Thiago,
On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote:
> IMA will need to know the key that signed a given PKCS#7 message, so add
> pkcs7_get_message_sig().
>
> It will also need to verify an already parsed PKCS#7 message. For this
> purpose, add verify_pkcs7_message_sig() whi
On 3/22/2018 11:27 AM, Luc Van Oostenryck wrote:
On Thu, Mar 22, 2018 at 11:16:55AM -0600, Logan Gunthorpe wrote:
Sparse produces a few warnings of the form:
lib/iomap.c:84:9: warning: cast to restricted __be16
(The kbuild robot has recently started running such checks)
Reviewed-by: Luc Van
On Thu, Mar 22, 2018 at 11:16:55AM -0600, Logan Gunthorpe wrote:
> Sparse produces a few warnings of the form:
>
> lib/iomap.c:84:9: warning: cast to restricted __be16
>
> (The kbuild robot has recently started running such checks)
Reviewed-by: Luc Van Oostenryck
Clean up the ifdefs which conditionally defined the io{read|write}64
functions in favour of the new common io-64-nonatomic-lo-hi header.
Per a nit from Andy Shevchenko, the include list is also made
alphabetical.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Andy Shevchenko
Cc: Jon Mason
---
dr
Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Andy Shevchenko
Acked-by: Dave Jiang
Acked-by: Allen Hubbe
Acked-by: Jon Mason
---
drivers/ntb/hw/
This is v14 of my cleanup series to push a number of instances of people
defining their own io{read|write}64 functions into common headers seing
they don't exist in non-64bit systems. This series adds inline functions to the
io-64-nonatomic headers and then cleans up the drivers that defined their
Subsequent patches in this series makes use of the readq and writeq
defines in iomap.h. However, as is, they get missed on the powerpc
platform seeing the include comes before the define. This patch
moves the include down to fix this.
Signed-off-by: Logan Gunthorpe
Acked-by: Michael Ellerman
Rev
This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).
The patch also points io{read|write}64[be] to the variant specified by the
header name.
This is because new drivers are enco
In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.
These functions are only defined if readq a
Sparse produces a few warnings of the form:
lib/iomap.c:84:9: warning: cast to restricted __be16
(The kbuild robot has recently started running such checks)
The warning is not valid because the __raw_readX() and __raw_writeX()
functions have an endianess determined by the semantics of whichever
Add support for io{read|write}64() functions in parisc architecture.
These are pretty straightforward copies of similar functions which
make use of readq and writeq.
Also, indicate that the lo_hi and hi_lo variants of these functions
are not provided by this architecture.
Signed-off-by: Logan Gun
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 cpu_to_beXX()
instead of beXX_to_cpu().
Seeing both beXX_to_cpu()
These functions will be introduced into the generic iomap.c so
they can deal with PIO accesses in hi-lo/lo-hi variants. Thus,
the powerpc version of iomap.c will need to provide the same
functions even though, in this arch, they are identical to the
regular io{read|write}64 functions.
Signed-off-b
Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64
functions in non-64bit cases in favour of the new common
io-64-nonatomic-lo-hi header.
To be consistent with CAAM engine HW spec: in case of 64-bit registers,
irrespective of device endianness, the lower address should be read from
Add rx path for tls software implementation.
recvmsg, splice_read, and poll implemented.
An additional sockopt TLS_RX is added, with the same interface as
TLS_TX. Either TLX_RX or TLX_TX may be provided separately, or
together (with two different setsockopt calls with appropriate keys).
Control
Pass EBADMSG explicitly to tls_err_abort. Receive path will
pass additional codes - EMSGSIZE if framing is larger than max
TLS record size, EINVAL if TLS version mismatch.
Signed-off-by: Dave Watson
---
include/net/tls.h | 6 +++---
net/tls/tls_sw.c | 2 +-
2 files changed, 4 insertions(+), 4
Refactor zerocopy_from_iter to take arguments for pages and size,
such that it can be used for both tx and rx. RX will also support
zerocopy direct to output iter, as long as the full message can
be copied at once (a large enough userspace buffer was provided).
Signed-off-by: Dave Watson
---
net
Add documentation on rx path setup and cmsg interface.
Signed-off-by: Dave Watson
---
Documentation/networking/tls.txt | 66 ++--
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/tls.txt b/Documentation/networking/tls.txt
Several config variables are prefixed with tx, drop the prefix
since these will be used for both tx and rx.
Signed-off-by: Dave Watson
---
include/net/tls.h | 2 +-
net/tls/tls_main.c | 26 +-
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/net/
Separate tx crypto parameters to a separate cipher_context struct.
The same parameters will be used for rx using the same struct.
tls_advance_record_sn is modified to only take the cipher info.
Signed-off-by: Dave Watson
---
include/net/tls.h | 26 +---
net/tls/tls_main.c |
TLS tcp socket RX implementation, to match existing TX code.
This patchset completes the software TLS socket, allowing full
bi-directional communication over TLS using normal socket syscalls,
after the handshake has been done in userspace. Only the symmetric
encryption is done in the kernel.
Thi
On Wed, Mar 21, 2018 at 07:00:48PM +0200, Tudor Ambarus wrote:
> There are few places in crypto where we save pointers to the
> authenc keys to a local variable of type struct crypto_authenc_keys
> and we don't zeroize it after use. Fix all those cases and don't
> leak pointers to the authenc keys.
Hello,
omap_aes_(cbc/ctr)(encrypt/decrypt) don't return the updated IV, add the
code to do just that at the end of the operation.
In omap_aes_done_task(), omap_crypto_cleanup() is called with:
omap_crypto_cleanup(&dd->out_sgl, dd->orig_out, 0, dd->total_save,
FLAGS_
Hello,
In omap_crypto_cleanup(),:
if (orig && (flags & OMAP_CRYPTO_COPY_MASK))
scatterwalk_map_and_copy(buf, orig, offset, len, 1);
implies that scatterwalk_map_and_copy() is called if flag is set to
OMAP_CRYPTO_SG_COPIED.
If the output buffer crosses a page boundary, the seco
Le 16/03/2018 à 15:07, Horia Geantă a écrit :
On 3/16/2018 2:42 PM, Christophe LEROY wrote:
Le 16/03/2018 à 09:48, Horia Geantă a écrit :
For SEC 2.x+, cipher in length must contain only the ciphertext length.
In case of using hardware ICV checking, the ICV length is provided via
the "extent"
For SEC 2.x+, cipher in length must contain only the ciphertext length.
In case of using hardware ICV checking, the ICV length is provided via
the "extent" field of the descriptor pointer.
Cc: # 4.8+
Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using
HMAC_SNOOP_NO_AFEU")
Repor
On Wed, Mar 21, 2018 at 07:00:55PM +0200, Tudor Ambarus wrote:
> Signed-off-by: Tudor Ambarus
Reviewed-by: Jamie Iles
> ---
> drivers/crypto/picoxcell_crypto.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/crypto/picoxcell_crypto.c
> b/drivers/crypto/picoxcell_crypto.c
>
Le 21/03/2018 à 18:00, Tudor Ambarus a écrit :
Signed-off-by: Tudor Ambarus
Reviewed-by: Christophe Leroy
---
drivers/crypto/talitos.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 447cb8b..c92efc7 100644
--- a/drivers/c
33 matches
Mail list logo