Fix the following whitescan warning:
Calling "zlib_inflateEnd(&ctx->decomp_stream)" is only useful for its
return value, which is ignored.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
crypto/deflate.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/crypto/deflate.c b/crypto/def
Hi Varad,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on crypto/master security/next-testing linus/master
v5.12-rc5 next-20210330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Reported-by: Hulk Robot
Signed-off-by: Tang Yizhou
---
drivers/crypto/ccp/ccp-crypto-main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/
From: Nick Terrell
Adds decompress_sources.h which includes every .c file necessary for
zstd decompression. This is used in decompress_unzstd.c so the internal
structure of the library isn't exposed.
This allows us to upgrade the zstd library version without modifying any
callers. Instead we jus
From: Nick Terrell
Please pull from
g...@github.com:terrelln/linux.git tags/v9-zstd-1.4.10
to get these changes. Alternatively the patchset is included.
This patchset upgrades the zstd library to the latest upstream release. The
current zstd version in the kernel is a modified version of ups
From: Nick Terrell
This patch:
- Moves `include/linux/zstd.h` -> `include/linux/zstd_lib.h`
- Updates modified zstd headers to yearless copyright
- Adds a new API in `include/linux/zstd.h` that is functionally
equivalent to the in-use subset of the current API. Functions are
renamed to avoid
On Tue, Mar 30, 2021 at 09:38:55AM -0700, Randy Dunlap wrote:
> On 3/29/21 10:29 PM, Eric Biggers wrote:
> > On Mon, Mar 29, 2021 at 10:06:51PM -0700, Randy Dunlap wrote:
> >> Having just seen a report of using "fips=1" on the kernel command line,
> >> I could not find it documented anywhere, so ad
The Kconfig help text for CRYPTO_FIPS says
config CRYPTO_FIPS
bool "FIPS 200 compliance"
...
help
This option enables the fips boot option which is
required if you want the system to operate in a FIPS 200
certification. You should say no unless you
On Wed, 2021-03-31 at 00:04 +0200, Richard Weinberger wrote:
> Ahmad,
>
> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum > wrote:
> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
>
> Is there a reason why we can't pass the desired backend name in the
> trusted key parameters?
> e.g.
Ahmad,
On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
Is there a reason why we can't pass the desired backend name in the
trusted key parameters?
e.g.
keyctl add trusted $KEYNAME "backendtype caam load $(cat ~/kmk.blob)" @s
--
Ahmad,
On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> TABLE="0 $BLOCKS crypt $ALGO :32:trusted:$KEYNAME 0 $DEV 0 1
> allow_discards"
> echo $TABLE | dmsetup create mydev
> echo $TABLE | dmsetup load mydev
Do you also plan to add support for this to cryptsetup?
David and I h
On Sun, Mar 28, 2021 at 11:37:23PM +0300, Jarkko Sakkinen wrote:
>
> Unfortunately, TPM trusted keys started this bad security practice, and
> obviously it cannot be fixed without breaking uapi backwards compatibility.
>
The whole point of a randomness source is that it is random. So userspace
Ahmad,
On Wed, Mar 17, 2021 at 3:03 PM Ahmad Fatoum wrote:
> > I didn't closely follow the previous discussions, but is a module
> > parameter really the right approach?
> > Is there also a way to set it via something like device tree?
>
> Compiled-on sources are considered in the order: tpm, te
Trigger RSA transform on the signature being verified from
psspad_verify, to produce intermediary data which will be handled
in the psspad_verify_complete callback.
Reference: https://tools.ietf.org/html/rfc8017#section-8.1.2
Signed-off-by: Varad Gautam
---
crypto/rsa-psspad.c | 53 +
keyctl pkey_* operations accept enc and hash parameters at present.
RSASSA-PSS signatures also require passing in the signature salt
length.
Add another parameter 'slen' to feed in salt length of a PSS
signature.
Signed-off-by: Varad Gautam
---
crypto/asymmetric_keys/asymmetric_type.c | 1 +
in
The RSA output must be processed as per the EMSA-PSS-VERIFY operation
from RFC8017, which forms the core of the PSS signature verification.
Implement the verification callback, which operates on the RSA output
buffer.
Reference: https://tools.ietf.org/html/rfc8017#section-9.1.2
Signed-off-by: Var
This generates a "mask" byte array of size mask_len bytes as a
concatenation of digests, where each digest is calculated on a
concatenation of an input seed and a running counter to fill up
mask_len bytes - as described by RFC8017 sec B.2.1. "MGF1".
The mask is useful for RSA signing/verification
Accept pss encoding for public_key_verify_signature. If
CONFIG_CRYPTO_RSASSA_PSS is disabled, crypto_alloc_akcipher will
fail to find a pss backend anyway.
Signed-off-by: Varad Gautam
---
crypto/asymmetric_keys/public_key.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-
RSASSA-PSS verify operation needs to compute digests for its
Mask Generation Function (MGF1), and for digest comparison.
Add helpers to populate a crypto_shash and desc for use in both cases.
Signed-off-by: Varad Gautam
---
crypto/rsa-psspad.c | 24
1 file changed, 24 i
Implement akcipher_alg->set_sig_params for rsassa-psspad to receive the
salt length for the signature being verified.
Signed-off-by: Varad Gautam
---
crypto/rsa-psspad.c | 20 +++-
include/crypto/internal/rsa-common.h | 1 +
2 files changed, 20 insertions(+), 1
For certain signature encoding schemes (eg. RSASSA-PSS), the
verify/sign operation behavior depends on information contained in
the signature blob. Allow passing this down to the crypto_template by
introducing a crypto_akcipher_set_sig_params() call.
Signed-off-by: Varad Gautam
---
crypto/rsa-co
Move helpers for setting public/private keys, RSA akcipher
instance setup, keysize querying etc. to rsa-common.c.
Signed-off-by: Varad Gautam
---
crypto/rsa-common.c | 183 +++
crypto/rsa-pkcs1pad.c| 183 ---
includ
The RSASSA-PSS signature scheme requires knowing the RSA modulus size
in bits. The rsa akcipher_alg max_size call is insufficient for this,
as the returned keysize is rounded up to the next byte.
Since the RSA modulus is stored as an MPI accessible via
struct rsa_mpi_key, move the struct definitio
Add a crypto_template for rsa-psspad, hidden behind
CONFIG_CRYPTO_RSASSA_PSS. Set the sign/verify/encrypt/decrypt
operations to return -EOPNOTSUPP, to be implemented in the future
Signed-off-by: Varad Gautam
---
crypto/Kconfig| 6 ++
crypto/Makefile | 1 +
cry
Move out helpers from rsa-pkcs1pad.c which will be shared across
rsa-*pad implementations.
Signed-off-by: Varad Gautam
---
crypto/Makefile | 1 +
crypto/rsa-common.c | 76 ++
crypto/rsa-pkcs1pad.c| 97 +---
Pull out more common code from rsa-pkcs1pad into rsa-common.
Signed-off-by: Varad Gautam
---
crypto/rsa-common.c | 31 +++
crypto/rsa-pkcs1pad.c| 32
include/crypto/internal/rsa-common.h | 9
3 files
rsa-pkcs1pad operations that require using RSA primitives rely on
creating an akcipher child RSA transform and processing the results
in the operation-specific callback. Add helpers
rsapad_akcipher_setup_child and rsapad_akcipher_req_complete for req
setup and callback handling, and switch pkcs1pad
The existing RSA implementation supports PKCSv1.5 style signature
paddings via rsa-pkcs1pad. A lot of the functionality implemented
for rsa-pkcs1pad can be reused across other RSA padding schemes.
Rename such functions as rsapad_* before moving them out of
rsa-pkcs1pad.c.
Signed-off-by: Varad Gaut
which can be reused by other signature padding schemes as
rsapad_akcipher_create. This will be moved out of rsa-pkcs1pad.c to
be used across rsa-*pad implementations.
Signed-off-by: Varad Gautam
---
crypto/rsa-pkcs1pad.c | 48 ++-
1 file changed, 34 insert
Use generic naming to share with other padding scheme implementations.
These will be moved out of rsa-pkcs1pad.c.
Signed-off-by: Varad Gautam
---
crypto/rsa-pkcs1pad.c | 62 +--
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/crypto/rsa-pkc
An X.509 wrapper for a RSASSA-PSS signature contains additional
signature parameters over the PKCSv.15 encoding scheme. Extend the
x509 parser to allow parsing RSASSA-PSS encoded certificates, with
the defaults taken from RFC8017.
A certificate is rejected if the hash function used for the MGF is
Linux currently supports RSA PKCSv1.5 encoding scheme for
signing / verification. This adds support for RSASSA PSS signature
verification as described in RFC8017 [1].
Patch 1 extends the x509 certificate parser to unpack PSS signature
parameters.
Patches 2-8 pull out the common functions / struc
On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > > Hi,
> > > > MD5 was marked incompliant with FIPS in 2009:
> >
On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
>
> On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > Hi,
> > > MD5 was marked incompliant with FIPS in 2009:
> > > a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_al
On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > Hi,
> > MD5 was marked incompliant with FIPS in 2009:
> > a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_allowed in fips
> > mode")
> > a1915d51e8e7 ("crypto: testmgr
On 3/29/21 10:29 PM, Eric Biggers wrote:
> On Mon, Mar 29, 2021 at 10:06:51PM -0700, Randy Dunlap wrote:
>> Having just seen a report of using "fips=1" on the kernel command line,
>> I could not find it documented anywhere, so add some help for it.
>>
>> Signed-off-by: Randy Dunlap
>> Cc: Dexuan C
On 3/30/21 10:46 AM, Rafael J. Wysocki wrote:
On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
Hi,
MD5 was marked incompliant with FIPS in 2009:
a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_allowed in fips
mode")
a1915d51e8e7 ("crypto: testmgr - Mark algs allowed in fips mode"
On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
>
> Hi,
> MD5 was marked incompliant with FIPS in 2009:
> a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_allowed in fips
> mode")
> a1915d51e8e7 ("crypto: testmgr - Mark algs allowed in fips mode")
>
> But hibernation_e820_save() is
On Tue, Mar 30, 2021 at 08:40:07PM +0800, tanghui20 wrote:
>
>
> On 2021/3/30 20:23, Greg KH wrote:
> > On Tue, Mar 30, 2021 at 08:09:46PM +0800, tanghui20 wrote:
> > >
> > >
> > > On 2021/3/28 23:09, Greg KH wrote:
> > > > On Sat, Mar 27, 2021 at 04:33:00PM +0800, Hui Tang wrote:
> > > > > 'xx
On 2021/3/30 20:23, Greg KH wrote:
On Tue, Mar 30, 2021 at 08:09:46PM +0800, tanghui20 wrote:
On 2021/3/28 23:09, Greg KH wrote:
On Sat, Mar 27, 2021 at 04:33:00PM +0800, Hui Tang wrote:
'xx_debugfs_init' check if debugfs opened.
Signed-off-by: Hui Tang
---
drivers/crypto/hisilicon/hpr
On Tue, Mar 30, 2021 at 08:09:46PM +0800, tanghui20 wrote:
>
>
> On 2021/3/28 23:09, Greg KH wrote:
> > On Sat, Mar 27, 2021 at 04:33:00PM +0800, Hui Tang wrote:
> > > 'xx_debugfs_init' check if debugfs opened.
> > >
> > > Signed-off-by: Hui Tang
> > > ---
> > > drivers/crypto/hisilicon/hpre/h
On 2021/3/28 23:09, Greg KH wrote:
On Sat, Mar 27, 2021 at 04:33:00PM +0800, Hui Tang wrote:
'xx_debugfs_init' check if debugfs opened.
Signed-off-by: Hui Tang
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 5 -
drivers/crypto/hisilicon/qm.c | 3 +++
drivers/crypto/hisilic
Do a trivial typo fix.
s/discribed/described
Reported-by: Hulk Robot
Signed-off-by: Ruiqi Gong
---
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_cr
On Tue, Mar 02, 2021 at 10:01:12AM +0100, Ard Biesheuvel wrote:
> Kernel mode NEON can be used in task or softirq context, but only in
> a non-nesting manner, i.e., softirq context is only permitted if the
> interrupt was not taken at a point where the kernel was using the NEON
> in task context.
>
Fix the following whitescan warning:
Assigning value "64" to "dst.address" here, but that stored value is
overwritten before it can be used.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/crypto/ccp/ccp-ops.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/
On Tue, Mar 02, 2021 at 10:01:11AM +0100, Ard Biesheuvel wrote:
> The AArch64 asm syntax has this slightly tedious property that the names
> used in mnemonics to refer to registers depend on whether the opcode in
> question targets the entire 64-bits (xN), or only the least significant
> 8, 16 or 3
On Tue, Mar 02, 2021 at 10:01:10AM +0100, Ard Biesheuvel wrote:
> The users of the conditional NEON yield macros have all been switched to
> the simplified cond_yield macro, and so the NEON specific ones can be
> removed.
>
> Signed-off-by: Ard Biesheuvel
> ---
> arch/arm64/include/asm/assembler
However, I think this log can be used to quickly locate the function or
module if dma alloc failed.
On 2021/3/30 15:56, Joe Perches wrote:
On Tue, 2021-03-30 at 15:39 +0800, Kai Ye wrote:
Add some dfx logs in some abnormal exit situations.
[]
diff --git a/drivers/crypto/hisilicon/sgl.c b/dr
ctx_q_num is a module parameter set by the user to specify the
number of qp queues required to create a ctx.
When the number of qp queues allocated by PF or VF is less than
the ctx_q_num, an error will be reported when ctx is initialized
in kernel mode, which leads to the problem that the register
On Tue, 2021-03-30 at 15:39 +0800, Kai Ye wrote:
> Add some dfx logs in some abnormal exit situations.
[]
> diff --git a/drivers/crypto/hisilicon/sgl.c b/drivers/crypto/hisilicon/sgl.c
[]
> @@ -87,8 +87,10 @@ struct hisi_acc_sgl_pool *hisi_acc_create_sgl_pool(struct
> device *dev,
>
On Tue, 2021-03-30 at 15:39 +0800, Kai Ye wrote:
> use a macro replace of a magic number.
Given the use of 32 in the same test, this
seems more obfuscating that useful to me.
> diff --git a/drivers/crypto/hisilicon/sgl.c b/drivers/crypto/hisilicon/sgl.c
[]
> @@ -9,6 +9,7 @@
> #define HISI_ACC_SG
Add clear data operation for sge data.
Signed-off-by: Kai Ye
---
drivers/crypto/hisilicon/sgl.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/sgl.c b/drivers/crypto/hisilicon/sgl.c
index c618aaf..7a58ab3 100644
--- a/drivers/crypto/hi
delete unneeded variable initialization
Signed-off-by: Kai Ye
---
drivers/crypto/hisilicon/sgl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/sgl.c b/drivers/crypto/hisilicon/sgl.c
index bd5ef40..b816e74 100644
--- a/drivers/crypto/hisilicon/sgl.c
Add some dfx logs in some abnormal exit situations.
Signed-off-by: Kai Ye
---
drivers/crypto/hisilicon/sgl.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/hisilicon/sgl.c b/drivers/crypto/hisilicon/sgl.c
index b816e74..4bece3d 100644
--- a/dr
The buffer of the hardware sge needs to be initialized by
soft sgl.
Signed-off-by: Kai Ye
---
drivers/crypto/hisilicon/sgl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/hisilicon/sgl.c b/drivers/crypto/hisilicon/sgl.c
index 4bece3d..c618aaf 100644
--- a/drivers/crypto/hisi
use a macro replace of a magic number.
Signed-off-by: Kai Ye
---
drivers/crypto/hisilicon/sgl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/sgl.c b/drivers/crypto/hisilicon/sgl.c
index 3bff639..bd5ef40 100644
--- a/drivers/crypto/hisilicon/sgl.
fixup coding style such as magic number and unneeded variable
initialization. Clear data operation in sg buf unmap, and other
misc fix.
Kai Ye (5):
crypto: hisilicon/sgl - fixup coding style
crypto: hisilicon/sgl - delete unneeded variable initialization
crypto: hisilicon/sgl - add some dfx
On Mon, 29 Mar 2021 at 01:07, Jarkko Sakkinen wrote:
>
> On Sat, Mar 27, 2021 at 01:41:24PM +0100, David Gstir wrote:
> > Hi!
> >
> > > On 25.03.2021, at 06:26, Sumit Garg wrote:
> > >
> > > On Wed, 24 Mar 2021 at 19:37, Ahmad Fatoum
> > > wrote:
> > >>
> > >> Hello Sumit,
> > >>
> > >> On 24.0
58 matches
Mail list logo
