Register SEC device to uacce framework for user space.
Signed-off-by: Kai Ye
Reviewed-by: Zhou Wang
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/sec2/sec_main.c | 39 +++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/s
Register HPRE device to uacce framework for user space.
Signed-off-by: Kai Ye
Reviewed-by: Zhou Wang
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.
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 - register HPRE device to uacce
crypto: hisilicon/sec - register SEC device
Add 'uacce_mode' parameter for ZIP, which can be set as 0(default) or 1.
'0' means ZIP is only registered to kernel crypto, and '1' means it's
registered to both kernel crypto and UACCE.
Signed-off-by: Kai Ye
Reviewed-by: Zhou Wang
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/qm.c
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 Xu
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/qm.c | 6
On Mon, Jan 04, 2021 at 08:53:48PM +0100, Carl Philipp Klemm wrote:
>
> I bisected this regession to the commit
> 00b99ad2bac256e3e4f10214c77fce6603afca26 "crypto: arm/aes-neonbs - Use
> generic cbc encryption path", reverting this commit and
> 5f254dd440fbad0c00632f9ac7645f07d8df9229 "crypto: cbc
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 data. It also breaks build with options:
CONFIG_DEBUG_INFO_BTF=y
C
On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> The HKDF addition is used to replace the implementation in the filesystem
> crypto extension. This code was tested by using an EXT4 encrypted file
> system that was created and contains files written to by the current
> implementatio
As a preparation to add the key derivation implementations, the
self-test data structure definition and the common test code is made
available.
The test framework follows the testing applied by the NIST CAVP test
approach.
The structure of the test code follows the implementations found in
crypto
Hi,
The key derviation functions are considered to be a cryptographic
operation. As cryptographic operations are provided via the kernel
crypto API, this patch set consolidates the KDF implementations into the
crypto API.
The KDF implementations are provided as service functions. Yet, the
interfa
SP800-108 defines three KDFs - this patch provides the counter KDF
implementation.
The KDF is implemented as a service function where the caller has to
maintain the hash / HMAC state. Apart from this hash/HMAC state, no
additional state is required to be maintained by either the caller or
the KDF
The kernel crypto API provides the SP800-108 counter KDF implementation.
Thus, the separate implementation provided as part of the keys subsystem
can be replaced with calls to the KDF offered by the kernel crypto API.
The keys subsystem uses the counter KDF with a hash cipher primitive.
Thus, it o
RFC5869 specifies an extract and expand two-step key derivation
function. The HKDF implementation is provided as a service function that
operates on a caller-provided HMAC cipher handle. The caller has to
allocate the HMAC cipher and then can invoke the HKDF service functions.
The HKDF implementati
As the kernel crypto API implements HKDF, replace the
file-system-specific HKDF implementation with the generic HKDF
implementation.
Signed-off-by: Stephan Mueller
---
fs/crypto/Kconfig | 2 +-
fs/crypto/fscrypt_private.h | 4 +-
fs/crypto/hkdf.c| 108 +-
Hi,
Im on Motorola XT894 and Motorola XT875. The Devices contain a texas
instruments wl1285c and wl1271c wifi chip respectively and use the
wlcore wl12xx driver. Since v5.10 the first attempt at connecting to an
encrypted ap will stall the userspace tool performing the operation
(eg. wpa_supplican
On Fri, Nov 20, 2020 at 10:52:54AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:33:54AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:51:45PM -0700, Eric Biggers wrote:
> > > On Fri, Sep 18, 2020 at 02:57:05PM -0700, Eric Biggers wrote:
> > > > On Fri, Sep 18, 2020 at 04:42:0
On Fri, Nov 20, 2020 at 10:52:35AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:34:03AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:50:58PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 15, 2020 at 09:36:52PM -0700, Eric Biggers wrote:
> > > > From: Eric Biggers
> > > >
>
On Fri, Nov 20, 2020 at 10:52:14AM -0800, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 09:33:43AM -0700, Eric Biggers wrote:
> > On Tue, Oct 06, 2020 at 08:50:21PM -0700, Eric Biggers wrote:
> > > On Tue, Sep 15, 2020 at 09:19:08PM -0700, Eric Biggers wrote:
> > > > From: Eric Biggers
> > > >
>
From: Adam Guerin
Restrict size of field to what is required by the operation.
This issue was detected by smatch:
drivers/crypto/qat/qat_common/qat_asym_algs.c:328 qat_dh_compute_value()
error: dma_map_single_attrs() '&qat_req->in.dh.in.b' too small (8 vs 64)
Signed-off-by: Adam Guerin
R
From: Adam Guerin
Cast ADF_SIZE_TO_RING_SIZE_IN_BYTES() so it can return a 64 bit value.
This issue was detected by smatch:
drivers/crypto/qat/qat_common/adf_transport_debug.c:65 adf_ring_show()
warn: should '(1 << (ring->ring_size - 1)) << 7' be a 64 bit type?
Signed-off-by: Adam Guerin
From: Adam Guerin
Sanitize ring_num value coming from configuration (and potentially
from user space) before it is used as index in the banks array.
This issue was detected by smatch:
drivers/crypto/qat/qat_common/adf_transport.c:233 adf_create_ring() warn:
potential spectre issue 'bank->r
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 - reduce size of mapped region
drivers/crypto/qat/qat_common/adf_transport.c
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
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 same type. If the ae mask is not identical for all devices
of the same type then
On Thu, Dec 10, 2020 at 02:03:11PM -0600, Rob Herring wrote:
> PicoXcell has had nothing but treewide cleanups for at least the last 8
> years and no signs of activity. The most recent activity is a yocto vendor
> kernel based on v3.0 in 2015.
>
> These patches can go via the respective maintainer
Device name: ccp-1
RNG name: ccp-1-rng
# Queues: 3
# Cmds: 0
Version: 5
Engines: AES 3DES SHA RSA ECC ZDE TRNG
Queues: 5
LSB Entries: 128
Let me know if you need anything else.
Domen
Domen, do you have the debugfs support enabled? Could you supply the output
from /sys/k
Replace the function pointers in the GCM implementation with static branches,
which are based on code patching, which occurs only at module load time.
This avoids the severe performance penalty caused by the use of retpolines.
In order to retain the ability to switch between different versions of
Currently, the gcm(aes-ni) driver open codes the scatterlist handling
that is encapsulated by the skcipher walk API. So let's switch to that
instead.
Also, move the handling at the end of gcmaes_crypt_by_sg() that is
dependent on whether we are encrypting or decrypting into the callers,
which alwa
Drop some prototypes that are declared but never called.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/aesni-intel_glue.c | 67
1 file changed, 67 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 880f9f8b5153..0f12
The gcm(aes-ni) driver is only built for x86_64, which does not make
use of highmem. So testing for PageHighMem is pointless and can be
omitted.
While at it, replace GFP_ATOMIC with the appropriate runtime decided
value based on the context.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/aes
The GCM mode driver uses 16 byte aligned buffers on the stack to pass
the IV to the asm helpers, but unfortunately, the x86 port does not
guarantee that the stack pointer is 16 byte aligned upon entry in the
first place. Since the compiler is not aware of this, it will not emit
the additional stack
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
Cc: Megha Dey
Cc: Eric Biggers
Cc: Herbert Xu
Ard Biesheuvel (5):
cry
On Mon, 4 Jan 2021 at 16:13, 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 Chiappero
Acked-b
The SEV FW version >= 0.23 added a new command that can be used to query
the attestation report containing the SHA-256 digest of the guest memory
encrypted through the KVM_SEV_LAUNCH_UPDATE_{DATA, VMSA} commands and
sign the report with the Platform Endorsement Key (PEK).
See the SEV FW API spec s
> On Tue, 22 Dec 2020 at 13:39, Marco Chiappero
> wrote:
>
> > diff --git a/drivers/crypto/qat/Kconfig b/drivers/crypto/qat/Kconfig
> > index beb379b23dc3..846a3d90b41a 100644
> > --- a/drivers/crypto/qat/Kconfig
> > +++ b/drivers/crypto/qat/Kconfig
> > @@ -11,6 +11,7 @@ config CRYPTO_DEV_QAT
> >
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 Chiappero
---
drivers/crypto/qat/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1
> On Mon, Jan 04, 2021 at 08:04:15AM +, Reshetova, Elena wrote:
> > > 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning
> > > to
> > >add SW fallback for P-192 in the driver, but the Intel Crypto team
> > >(which, internally, has to approve any code involving cr
On 12/28/20 9:22 AM, John Allen wrote:
On Thu, Dec 17, 2020 at 07:42:52AM +, Domen Stangar wrote:
Hi,
I would like to report issue with ccp-crypto.
When I issue modprobe command, it would not continue, without SIGINT signal
(ctrl+c).
If module is compiled in kernel, boot doesn't finish.
Look
On Mon, Jan 04, 2021 at 11:36:57AM +, Alessandrelli, Daniele wrote:
>
> Herbert, should I send an updated RFC now or should I wait for the
> discussion on the RFC open points to be completed first?
I think you should wait for the existing discussion to settle
first before sending out an update
On Sun, 2021-01-03 at 09:07 +1100, Herbert Xu wrote:
> On Wed, Dec 16, 2020 at 11:46:34AM +, Daniele Alessandrelli
> wrote:
> > The Intel Keem Bay SoC has an Offload Crypto Subsystem (OCS)
> > featuring a
> > Hashing Control Unit (HCU) for accelerating hashing operations.
> >
> > This driver a
On Mon, 2021-01-04 at 17:36 +0800, yumeng wrote:
>
> 在 2021/1/3 5:29, Herbert Xu 写道:
> > On Thu, Dec 24, 2020 at 02:08:25PM +0800, Meng Yu wrote:
> > > Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h',
> > > so all can use it,
> > >
> > > Signed-off-by: Meng Yu
> > > Reviewed
On Mon, Jan 04, 2021 at 04:15:13PM +0800, liulongfang wrote:
>
> Currently, we have not conducted Fuzz testing.
> For SEC driver, we only adds support for these new algorithms
> with existing interfaces of Crypto. So, do we need to do Fuzz testing on the
> existing interfaces?
Please test with CR
On Mon, Jan 04, 2021 at 08:04:15AM +, Reshetova, Elena wrote:
> > 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning to
> >add SW fallback for P-192 in the driver, but the Intel Crypto team
> >(which, internally, has to approve any code involving cryptography)
> >
在 2021/1/3 5:29, Herbert Xu 写道:
On Thu, Dec 24, 2020 at 02:08:25PM +0800, Meng Yu wrote:
Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h',
so all can use it,
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 1 -
crypto/ecc.h
On 2021/1/3 5:00, Herbert Xu wrote:
> On Thu, Dec 10, 2020 at 07:10:01PM +0800, Longfang Liu wrote:
>> Add support for new algorithms of SEC accelerator on Kunpeng930,
>> the driver and test case needs to be updated
>>
>> Longfang Liu (5):
>> crypto: hisilicon/sec - add new type of sqe for Kunpen
> 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning to
>add SW fallback for P-192 in the driver, but the Intel Crypto team
>(which, internally, has to approve any code involving cryptography)
>advised against it, because they consider P-192 weak. As a result, the
46 matches
Mail list logo
