On Tue, Jan 05, 2021 at 12:02:37AM +0100, Jiri Olsa wrote:
> Renaming 'struct device_private' to 'struct bcm_device_private',
> because it clashes with 'struct device_private' from
> 'drivers/base/base.h'.
>
> While it's not a functional problem, it's causing two distinct
> type hierarchies in BTF
On Wed, Jan 06, 2021 at 12:25:08PM +0300, Dan Carpenter wrote:
> The first argument to WARN() is a condition and the messages is the
> second argument is the string, so this WARN() will only display the
> __func__ part of the message.
>
> Fixes: ae832e329a8d ("crypto: keembay-ocs-hcu - Add HMAC su
On Wed, Jan 06, 2021 at 03:27:33PM +, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli
>
> Add the following additional dependencies for CRYPTO_DEV_KEEMBAY_OCS_HCU:
>
> - HAS_IOMEM to prevent build failures
>
> - ARCH_KEEMBAY to prevent asking the user about this driver when
> c
On Mon, Jan 04, 2021 at 05:21:56PM +, Giovanni Cabiddu wrote:
> Fix warnings and errors reported by the static analysis tool smatch in
> the QAT driver.
>
> Adam Guerin (3):
> crypto: qat - fix potential spectre issue
> crypto: qat - change format string and cast ring size
> crypto: qat
On Tue, Jan 05, 2021 at 03:31:08PM +0530, Bhaskar Chowdhury wrote:
>
> s/fautly/faulty/p
>
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/crypto/marvell/cesa/tdma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://g
On Tue, Jan 05, 2021 at 05:47:48PM +0100, Ard Biesheuvel wrote:
> NOTE: this is a follow-up to '[RFC PATCH 00/10] crypto: x86 - remove XTS and
> CTR glue helper code' [0].
>
> After applying my performance fixes for AES-NI in XTS mode, the only
> remaining users of the x86 glue helper module are t
On Mon, Jan 04, 2021 at 04:55:45PM +0100, Ard Biesheuvel wrote:
> Clean up some issues and peculiarities in the gcm(aes-ni) driver.
>
> Changes since v1:
> - fix sleep while atomic issue reported by Eric
> - add patch to get rid of indirect calls, to avoid taking the retpoline
> performance hit
On Mon, Jan 04, 2021 at 04:55:46PM +, Giovanni Cabiddu wrote:
> From: Wojciech Ziemba
>
> The hardware specific function adf_get_arbiter_mapping() modifies
> the static array thrd_to_arb_map to disable mappings for AEs
> that are disabled. This static array is used for each device
> of the sa
On Tue, Jan 05, 2021 at 02:12:03PM +0800, Kai Ye wrote:
> Kunpeng920 SEC/HPRE/ZIP cannot support running user space SVA and kernel
> Crypto at the same time. Therefore, the algorithms should not be registered
> to Crypto as user space SVA is enabled.
>
> Signed-off-by: Kai Ye
> Reviewed-by: Zaibo
On Tue, Jan 05, 2021 at 02:16:41PM +0800, Kai Ye wrote:
> 1. Add parameter of UACCE mode selection for ZIP.
> 2. Register SEC and HPRE devices to UACCE framework for user space drivers.
>
> Kai Ye (3):
> crypto: hisilicon - add ZIP device using mode parameter
> crypto: hisilicon/hpre - registe
On Mon, Jan 04, 2021 at 03:35:15PM +, Marco Chiappero wrote:
> Use CRYPTO_LIB_AES in place of CRYPTO_AES in the dependences for the QAT
> common code.
>
> Fixes: c0e583ab2016 ("crypto: qat - add CRYPTO_AES to Kconfig dependencies")
> Reported-by: Ard Biesheuvel
> Signed-off-by: Marco Chiapper
On Wed, Jan 06, 2021 at 04:12:18PM +0530, Srujana Challa wrote:
>
> +static int cpt_ucode_load_fw(struct pci_dev *pdev, struct fw_info_t *fw_info)
> +{
> + char filename[OTX2_CPT_NAME_LENGTH];
> + char eng_type[8] = {0};
> + int ret, e, i;
> +
> + INIT_LIST_HEAD(&fw_info->ucodes);
>
This patch fixes a number of sparse warnings in the bcm driver.
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index 0e5537838ef3..851b149f7170 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -471,10 +471,8 @@ static
On Tue, Jan 12, 2021 at 05:15:40PM +0100, Geert Uytterhoeven wrote:
> The Intel Keem Bay Offload and Crypto Subsystem (OCS) Hash Control Unit
> (HCU) is only present on Intel Keem Bay SoCs. Hence add a dependency on
> ARCH_KEEMBAY, to prevent asking the user about this driver when
> configuring a
On Sun, Jan 10, 2021 at 06:57:10AM +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 05, 2021 at 11:12:57AM +0100, Mickaël Salaün wrote:
> > Jarkko, David, what is the status of this patch series? Do you need help
> > to test it?
>
> Hi, a leave/vacation and the holiday period badly mixed my schedules.
On Wed, Jan 13, 2021 at 11:11:13AM +, David Howells wrote:
> I'm intending to use Tianjia's patch. Would you like to add a Reviewed-by?
>
> David
I can give.
Reviewed-by: Jarkko Sakkinen
/Jarkko
> ---
> commit 11078a592e6dcea6b9f30e822d3d30e3defc99ca
> Author: Tianjia Zhang
> Date: Th
> On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen
> wrote:
>
> On Tue, Jan 12, 2021 at 02:57:39PM +, David Howells wrote:
>> Eric Snowberg wrote:
>>
On Dec 10, 2020, at 2:49 AM, David Howells wrote:
Eric Snowberg wrote:
> Add support for EFI_CERT_X509_GUID dbx en
On Wed, 2021-01-13 at 13:40 +, David Howells wrote:
> Hi Linus,
>
> Are you willing to take this between merge windows - or does it need
> to wait for the next merge window? It's not technically a bug fix to
> the kernel, but it does have a CVE attached to it.
>
> Note that I've also updated
On Tue, Jan 12, 2021 at 02:57:39PM +, David Howells wrote:
> Eric Snowberg wrote:
>
> > > On Dec 10, 2020, at 2:49 AM, David Howells wrote:
> > >
> > > Eric Snowberg wrote:
> > >
> > >> Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
> > >> is found, it is added
David Howells wrote:
> This fixes CVE-2020-26541.
Note that I added the CVE number, not Eric.
David
On Tue, Jan 12, 2021 at 07:16:37AM +0530, Allen Pais wrote:
> From: Allen Pais
>
> In preparation for unconditionally passing the
> struct tasklet_struct pointer to all tasklet
> callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
>
> S
Hi Linus,
Are you willing to take this between merge windows - or does it need to wait
for the next merge window? It's not technically a bug fix to the kernel, but
it does have a CVE attached to it.
Note that I've also updated Jarkko's address in his Reviewed-by since his
Intel address no longer
From: Tianjia Zhang
On the following call path, `sig->pkey_algo` is not assigned
in asymmetric_key_verify_signature(), which causes runtime
crash in public_key_verify_signature().
keyctl_pkey_verify
asymmetric_key_verify_signature
verify_signature
public_key_verify_signature
From: Tianjia Zhang
On the following call path, `sig->pkey_algo` is not assigned
in asymmetric_key_verify_signature(), which causes runtime
crash in public_key_verify_signature().
keyctl_pkey_verify
asymmetric_key_verify_signature
verify_signature
public_key_verify_signature
Toke Høiland-Jørgensen wrote:
> Reviewed-by: Toke Høiland-Jørgensen
>
> and also, if you like:
>
> Tested-by: Toke Høiland-Jørgensen
Thanks!
David
On Tue, 12 Jan 2021 at 20:30, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Remove some dead code that was left over following commit 90ea1c6436d2
> ("random: remove the blocking pool").
>
> Cc: linux-crypto@vger.kernel.org
> Cc: Andy Lutomirski
> Cc: Jann Horn
> Cc: Theodore Ts'o
> Reviewed-
On Tue, 12 Jan 2021 at 20:30, Eric Biggers wrote:
>
> From: Eric Biggers
>
> On big endian CPUs, the ChaCha20-based CRNG is using the wrong
> endianness for the ChaCha20 constants.
>
> This doesn't matter cryptographically, but technically it means it's not
> ChaCha20 anymore. Fix it to always u
On Tue, 12 Jan 2021 at 20:30, Eric Biggers wrote:
>
> From: Eric Biggers
>
> The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
> doesn't make sense. Reseed it from the input_pool instead.
>
> Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
> Cc: sta...@vger.kernel.o
David Howells writes:
> I'm intending to use Tianjia's patch.
Yeah, sorry for missing that.
> Would you like to add a Reviewed-by?
Sure:
Reviewed-by: Toke Høiland-Jørgensen
and also, if you like:
Tested-by: Toke Høiland-Jørgensen
Tianjia Zhang writes:
> Hi,
>
> I have fixed this problem last week. Still thanks for your fixing.
> patch is here: https://lkml.org/lkml/2021/1/7/201
Ah, awesome! I did look if this had already been fixed, but your patch
wasn't in the crypto tree and didn't think to go perusing the mailing
list
I'm intending to use Tianjia's patch. Would you like to add a Reviewed-by?
David
---
commit 11078a592e6dcea6b9f30e822d3d30e3defc99ca
Author: Tianjia Zhang
Date: Thu Jan 7 17:28:55 2021 +0800
X.509: Fix crash caused by NULL pointer
On the following call path, `sig->pkey_algo` is n
Unlike many other structure types defined in the crypto API, the
'shash_desc' structure is permitted to live on the stack, which
implies its contents may not be accessed by DMA masters. (This is
due to the fact that the stack may be located in the vmalloc area,
which requires a different virtual-to
Hi Thara,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on cryptodev/master]
[also build test ERROR on crypto/master v5.11-rc3 next-20210113]
[cannot apply to sparc-next/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Wed, 13 Jan 2021 at 07:27, Herbert Xu wrote:
>
> On Fri, Jan 08, 2021 at 11:49:32PM +0100, Ard Biesheuvel wrote:
> >
> > The assumption is that ARCH_SLAB_MINALIGN should be sufficient for any
> > POD type, But I guess that in order to be fully correct, the actual
> > alignment of the struct typ
34 matches
Mail list logo
