On Wed, 5 Mar 2025 at 00:52, Bart Van Assche wrote:
>
> On 3/4/25 1:21 AM, Marco Elver wrote:
> > +#include
> > +
> > +/*
> > + * Test that helper macros work as expected.
> > + */
> > +static void __used test_common_helpers(void)
> > +{
On 3/4/25 1:21 AM, Marco Elver wrote:
+#include
+
+/*
+ * Test that helper macros work as expected.
+ */
+static void __used test_common_helpers(void)
+{
+ BUILD_BUG_ON(capability_unsafe(3) != 3); /* plain expression */
+ BUILD_BUG_ON(capability_unsafe((void)2; 3;) != 3); /* does
Add a simple test stub where we will add common supported patterns that
should not generate false positive of each new supported capability.
Signed-off-by: Marco Elver
---
lib/Kconfig.debug | 14 ++
lib/Makefile | 3 +++
lib/test_capability-analysis.c
Extend sev_smoke_test to also run a minimal SEV-SNP smoke test that
initializes and sets up private memory regions required to run a simple
SEV-SNP guest.
Similar to its SEV-ES smoke test counterpart, this also does not
support GHCB and ucall yet and uses the GHCB MSR protocol to trigger an
exit
Add the X86_FEATURE_SEV_SNP CPU feature to the architectural definition
for the SEV-SNP VM type to exercise the KVM_SEV_INIT2 call. Ensure that
the SNP test is skipped in scenarios where CPUID supports it but KVM
does not, preventing reporting of failure in such cases.
Reviewed-by: Nikunj A
5 +244,20 @@ int main(int argc, char *argv[])
>>>>}
>>>>}
>>>>
>>>> + if (kvm_cpu_has(X86_FEATURE_SEV_SNP)) {
>>>> + uint64_t snp_policy = snp_default_policy();
>>>> +
>>>> + test_snp(snp_polic
;>
> >> + if (kvm_cpu_has(X86_FEATURE_SEV_SNP)) {
> >> + uint64_t snp_policy = snp_default_policy();
> >> +
> >> + test_snp(snp_policy);
> >> + /* Test minimum firmware level */
> >> + test_snp(snp_
int64_t snp_policy = snp_default_policy();
>> +
>> + test_snp(snp_policy);
>> +/* Test minimum firmware level */
>> +test_snp(snp_policy | SNP_FW_VER_MAJOR(SNP_MIN_API_MAJOR) |
>> +SNP_FW_VER_MINOR(SNP_MIN_API_MINOR));
test_snp(snp_policy);
> + /* Test minimum firmware level */
> + test_snp(snp_policy | SNP_FW_VER_MAJOR(SNP_MIN_API_MAJOR) |
> + SNP_FW_VER_MINOR(SNP_MIN_API_MINOR));
Ah, this is where the firmware policy stuff is used. Refresh me, can userspace
request
Add a simple test stub where we will add common supported patterns that
should not generate false positive of each new supported capability.
Signed-off-by: Marco Elver
---
lib/Kconfig.debug | 14 ++
lib/Makefile | 3 +++
lib/test_capability-analysis.c
Extend sev_smoke_test to also run a minimal SEV-SNP smoke test that
initializes and sets up private memory regions required to run a simple
SEV-SNP guest.
Similar to its SEV-ES smoke test counterpart, this also does not
support GHCB and ucall yet and uses the GHCB MSR protocol to trigger an
exit
Add the X86_FEATURE_SEV_SNP CPU feature to the architectural definition
for the SEV-SNP VM type to exercise the KVM_SEV_INIT2 call. Ensure that
the SNP test is skipped in scenarios where CPUID supports it but KVM
does not, preventing reporting of failure in such cases.
Reviewed-by: Nikunj A
Hi Nikunj
On 1/28/25 6:13 AM, Nikunj A Dadhania wrote:
> "Pratik R. Sampat" writes:
>
>> Add the X86_FEATURE_SNP CPU feature to the architectural definition for
>> the SEV-SNP VM type to exercise the KVM_SEV_INIT2 call. Ensure that the
>> SNP test is skipped in
"Pratik R. Sampat" writes:
> Add the X86_FEATURE_SNP CPU feature to the architectural definition for
> the SEV-SNP VM type to exercise the KVM_SEV_INIT2 call. Ensure that the
> SNP test is skipped in scenarios where CPUID supports it but KVM does
> not, preventing report
Extend sev_smoke_test to also run a minimal SEV-SNP smoke test that
initializes and sets up private memory regions required to run a simple
SEV-SNP guest.
Similar to its SEV-ES smoke test counterpart, this also does not
support GHCB and ucall yet and uses the GHCB MSR protocol to trigger an
exit
Add the X86_FEATURE_SNP CPU feature to the architectural definition for
the SEV-SNP VM type to exercise the KVM_SEV_INIT2 call. Ensure that the
SNP test is skipped in scenarios where CPUID supports it but KVM does
not, preventing reporting of failure in such cases.
Signed-off-by: Pratik R. Sampat
tomic_dec to be reordered
> thus resulting in an underflow.
>
> Thanks,
I've tested v3 patch on s390 for the boot OOM problem with 'mem=1G'
kernel parameter we experience on current linux-next kernel and confirm
that the issue is no longer present.
Tested-by: Mikhail
On Tue, Jan 14, 2025 at 11:15:19AM +0800, Herbert Xu wrote:
Hi Herbert,
> Thanks for testing! The patch needs one more change though as
> moving the atomic_inc outside of the lock was a bad idea on my
> part. This could cause atomic_inc/atomic_dec to be reordered
> thus resulting in an underflow
On Wed, Jan 15, 2025 at 07:15:46AM -0800, Breno Leitao wrote:
>
> Something like the following (not tested):
>
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index 3e555d012ed60..5a0ec71e990ee 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -554,7
On Tue, Jan 14, 2025 at 11:15:19AM +0800, Herbert Xu wrote:
> On Fri, Jan 10, 2025 at 06:22:40PM +, Michael Kelley wrote:
> >
> > This patch passes my tests. I'm doing a narrow test to verify that
> > the boot failure when opening the Mellanox NIC is no longer occu
From: Herbert Xu Sent: Monday, January 13, 2025
7:15 PM
>
> On Fri, Jan 10, 2025 at 06:22:40PM +, Michael Kelley wrote:
> >
> > This patch passes my tests. I'm doing a narrow test to verify that
> > the boot failure when opening the Mellanox NIC is no longer o
On Fri, Jan 10, 2025 at 06:22:40PM +, Michael Kelley wrote:
>
> This patch passes my tests. I'm doing a narrow test to verify that
> the boot failure when opening the Mellanox NIC is no longer occurring.
> I also unloaded/reloaded the mlx5 driver a couple of times. For good
l wraparounds in a particular piece of code, so that the code can
>be run with the corresponding sanitizer enabled, wouldn't it be necessary to
>actually test the code with that sanitizer enabled to find all the cases?
Yes, but there's a lot of code to test -- I'm trying to get the
e to the position where we can meaningfully
> instrument arithmetic wrap-around conditions and catch them when they
> are unexpected, regardless of whether they are signed[2], unsigned[3],
> or pointer[4] types.
>
> Refactor open-coded wrap-around addition test to use add_would_overflow().
&
re unexpected, regardless of whether they are signed[2], unsigned[3],
or pointer[4] types.
Refactor open-coded wrap-around addition test to use add_would_overflow().
This paves the way to enabling the wrap-around sanitizers in the future.
Link: https://git.ker
re unexpected, regardless of whether they are signed[2], unsigned[3],
or pointer[4] types.
Refactor open-coded wrap-around addition test to use add_would_overflow().
This paves the way to enabling the wrap-around sanitizers in the future.
Link: https://git.ker
This patch adds the test vector for rsa with pss encoding.
Signed-off-by: Hongbo Li
---
crypto/testmgr.c | 7 +
crypto/testmgr.h | 90
2 files changed, 97 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 10c5b3b
This patch adds the test vector for rsa with pss encoding.
Signed-off-by: Hongbo Li
---
crypto/testmgr.c | 7 +
crypto/testmgr.h | 90
2 files changed, 97 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 10c5b3b
This patch adds the test vector for rsa with pss encoding.
Signed-off-by: Hongbo Li
---
crypto/testmgr.c | 7 +
crypto/testmgr.h | 90
2 files changed, 97 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 10c5b3b
From: Hongbo Li
This patch adds the test vector for rsa with pss encoding.
Signed-off-by: Hongbo Li
---
crypto/testmgr.c | 7 +
crypto/testmgr.h | 87
2 files changed, 94 insertions(+)
diff --git a/crypto/testmgr.c b/crypto
From: Saulo Alessandre
Register NIST P384 as an akcipher and extend the testmgr with
NIST P384-specific test vectors.
Summary of changes:
* crypto/ecdsa.c
- add ecdsa_nist_p384_init_tfm
- register and unregister P384 tfm
* crypto/testmgr.c
- add test vector for P384 on vector of tests
On Fri, Mar 05, 2021 at 03:59:51PM -0500, Stefan Berger wrote:
> From: Saulo Alessandre
>
> Register NIST P384 as an akcipher and extend the testmgr with
> NIST P384-specific test vectors.
>
> Summary of changes:
>
> * crypto/ecdsa.c
> - add ecdsa_nist_p384_
From: Saulo Alessandre
Register NIST P384 as an akcipher and extend the testmgr with
NIST P384-specific test vectors.
Summary of changes:
* crypto/ecdsa.c
- add ecdsa_nist_p384_init_tfm
- register and unregister P384 tfm
* crypto/testmgr.c
- add test vector for P384 on vector of tests
On 3/5/21 12:10 PM, Jarkko Sakkinen wrote:
On Thu, Mar 04, 2021 at 07:51:58PM -0500, Stefan Berger wrote:
From: Saulo Alessandre
* crypto/ecdsa.c
- add ecdsa_nist_p384_init_tfm
- register and unregister P384 tfm
* crypto/testmgr.c
- add test vector for P384 on vector of tests
On Thu, Mar 04, 2021 at 07:51:58PM -0500, Stefan Berger wrote:
> From: Saulo Alessandre
>
> * crypto/ecdsa.c
> - add ecdsa_nist_p384_init_tfm
> - register and unregister P384 tfm
>
> * crypto/testmgr.c
> - add test vector for P384 on vector of tests
>
> * c
From: Saulo Alessandre
* crypto/ecdsa.c
- add ecdsa_nist_p384_init_tfm
- register and unregister P384 tfm
* crypto/testmgr.c
- add test vector for P384 on vector of tests
* crypto/testmgr.h
- add test vector params for P384(sha1, sha224, sha256, sha384
and sha512)
Signed-off-by
On 2021/3/4 12:41, Herbert Xu wrote:
> On Sat, Feb 20, 2021 at 05:51:22PM +0800, liulongfang wrote:
> .
>> Since patch3 is an unnecessary patch,
>> can you just remove it and merge patch1 and patch2?
>
> Please repost.
>
> Thanks,
>
Ok.
Thanks,
Longfang
On Sat, Feb 20, 2021 at 05:51:22PM +0800, liulongfang wrote:
.
> Since patch3 is an unnecessary patch,
> can you just remove it and merge patch1 and patch2?
Please repost.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/p
From: Saulo Alessandre
* crypto/ecdsa.c
- add ecdsa_nist_p384_init_tfm
- register and unregister P384 tfm
* crypto/testmgr.c
- add test vector for P384 on vector of tests
* crypto/testmgr.h
- add test vector params for P384(sha1, sha224, sha256, sha384
and sha512)
Signed-off-by
On 2021/2/5 19:44, Herbert Xu Wrote:
> On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote:
>> If this configuration item is not turned on,
>> the allocation of crypto_tfm will fail when
>> the shash algorithm calculates the hash
>> through the software.
>>
>> Signed-off-by: Longfang Liu
ready included that.
>
> Cheers,
>
On this kernel version, those modules set to Y will not use the sha512
algorithm.
And our SEC module selects it "select CRYPTO_SHA512", so it is compiled into
ko: "sha512_generic.ko".
Because we did not load the "sha512_generic.ko" when we loaded the ko of SEC,
the sha512 algorithm test failed, Therefore, before using SEC,
we need to load this ko first, so this patch is not required, please ignore it.
Thanks
Longfang.
On Thu, Feb 18, 2021 at 10:01:58AM +0800, liulongfang wrote:
>
> >> diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c
> >> b/drivers/crypto/hisilicon/sec2/sec_crypto.c
> >> index d2c4a2c..988faf7 100644
> >> --- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
> >> +++ b/drivers/crypto/hisilicon
On 2021/2/10 14:43, Herbert Xu Wrote:
> On Sun, Feb 07, 2021 at 06:04:40PM +0800, Longfang Liu wrote:
>> If the header file "crypto/internal/hash.h" not
>> added, the allocation of crypto_tfm will fail when
>> the shash algorithm calculates the hash
>> through the software.
>>
>> Signed-off-by: Lon
On Sun, Feb 07, 2021 at 06:04:40PM +0800, Longfang Liu wrote:
> If the header file "crypto/internal/hash.h" not
> added, the allocation of crypto_tfm will fail when
> the shash algorithm calculates the hash
> through the software.
>
> Signed-off-by: Longfang Liu
> ---
> drivers/crypto/hisilicon/
If the header file "crypto/internal/hash.h" not
added, the allocation of crypto_tfm will fail when
the shash algorithm calculates the hash
through the software.
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec_crypto.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
On 2021/2/7 16:02, Ard Biesheuvel wrote:
> On Sun, 7 Feb 2021 at 03:47, liulongfang wrote:
>>
>> On 2021/2/5 19:44, Herbert Xu write:
>>> On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote:
If this configuration item is not turned on,
the allocation of crypto_tfm will fail when
On Sun, 7 Feb 2021 at 03:47, liulongfang wrote:
>
> On 2021/2/5 19:44, Herbert Xu write:
> > On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote:
> >> If this configuration item is not turned on,
> >> the allocation of crypto_tfm will fail when
> >> the shash algorithm calculates the hash
On 2021/2/5 19:44, Herbert Xu write:
> On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote:
>> If this configuration item is not turned on,
>> the allocation of crypto_tfm will fail when
>> the shash algorithm calculates the hash
>> through the software.
>>
>> Signed-off-by: Longfang Liu
If this configuration item is not turned on,
the allocation of crypto_tfm will fail when
the shash algorithm calculates the hash
through the software.
Signed-off-by: Longfang Liu
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/confi
On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote:
> If this configuration item is not turned on,
> the allocation of crypto_tfm will fail when
> the shash algorithm calculates the hash
> through the software.
>
> Signed-off-by: Longfang Liu
> ---
> arch/arm64/configs/defconfig | 2 +-
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
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
From: Kyung Min Park
Add speed test for optimized GHASH computations with vectorized
instructions. Introduce a new test suite to calculate the speed
for this algorithm.
Signed-off-by: Kyung Min Park
Signed-off-by: Megha Dey
---
crypto/tcrypt.c | 5 +
1 file changed, 5 insertions(+)
diff
> On Dec 18, 2020, at 18:59, Peter Zijlstra wrote:
>
> On Wed, Dec 16, 2020 at 09:41:44AM -0800, Chang S. Bae wrote:
>> +/* ENCODEKEY128 %EAX */
>> +asm volatile (".byte 0xf3, 0xf, 0x38, 0xfa, 0xc0");
>
> This is lacking a binutils version number.
I will add the version number when an
On Wed, Dec 16, 2020 at 09:41:44AM -0800, Chang S. Bae wrote:
> + /* ENCODEKEY128 %EAX */
> + asm volatile (".byte 0xf3, 0xf, 0x38, 0xfa, 0xc0");
This is lacking a binutils version number. Boris, didn't you do a
checkpatch.pl thing for that?
The test validates the internal key to be the same in all CPUs.
It performs the validation again with the Suspend-To-RAM (ACPI S3) state.
Signed-off-by: Chang S. Bae
Cc: linux-ker...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
---
tools/testing/selftests/x86/Makefile| 2 +-
tools
onst struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "ccm(sm4)",
+ .test = alg_test_aead,
+ .fips_allowed = 1,
+ .suite = {
+ .aead = {
+ VECS(sm4_ccm_tv_template),
+
On Fri, Nov 27, 2020 at 11:18:12AM +0100, Uros Bizjak wrote:
> CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg
> instruction when only zero and sign flags are checked (E,L,LE,G,GE
> conditions).
>
> Signed-off-by: Uros Bizjak
> Cc: Herbert Xu
On Fri, Nov 27, 2020 at 10:59:43AM +0100, Uros Bizjak wrote:
> CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg
> instruction when only zero and sign flags are checked (E,L,LE,G,GE
> conditions).
>
> Signed-off-by: Uros Bizjak
> Cc: Herbert Xu
On Fri, Nov 27, 2020 at 10:44:52AM +0100, Uros Bizjak wrote:
> CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg
> instruction when only zero and sign flags are checked (E,L,LE,G,GE
> conditions).
>
> Signed-off-by: Uros Bizjak
> Cc: Herbert Xu
On Wed, Nov 25, 2020 at 11:03:08PM -0300, Saulo Alessandre wrote:
> From: Saulo Alessandre
>
> Signed-off-by: Saulo Alessandre
> ---
> Documentation/admin-guide/module-signing.rst | 10 +
> crypto/Kconfig | 12 +
> crypto/Makefile |
CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg
instruction when only zero and sign flags are checked (E,L,LE,G,GE conditions).
Signed-off-by: Uros Bizjak
Cc: Herbert Xu
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
---
arch/x86/crypto/poly1305-x86_64-cr
CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg
instruction when only zero and sign flags are checked (E,L,LE,G,GE conditions).
Signed-off-by: Uros Bizjak
Cc: Herbert Xu
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
---
arch/x86/crypto/sha512-avx-asm.S |
CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg
instruction when only zero and sign flags are checked (E,L,LE,G,GE conditions).
Signed-off-by: Uros Bizjak
Cc: Herbert Xu
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
---
arch/x86/crypto/aesni-intel_as
= OBJECT IDENTIFIER ({ ecdsa_param_curve })
diff --git a/crypto/ecdsa_signature.asn1 b/crypto/ecdsa_signature.asn1
new file mode 100644
index 0..378e73913
--- /dev/null
+++ b/crypto/ecdsa_signature.asn1
@@ -0,0 +1,6 @@
+EcdsaSignature ::= SEQUENCE {
+signatureR INTEGER ({ ecdsa_parse_sig_r
Eric Biggers wrote:
> From: Eric Biggers
>
> Currently, by default crypto self-test failures only result in a
> pr_warn() message and an "unknown" status in /proc/crypto. Both of
> these are easy to miss. There is also an option to panic the kernel
> when a test
Add test vectors for the use of the EBOIV template with cbc(aes)
modes as it is being used by dm-crypt for BitLocker support.
Vectors taken from dm-crypt test suite images.
Signed-off-by: Gilad Ben-Yossef
---
crypto/tcrypt.c | 9 ++
crypto/testmgr.c | 6 +
crypto/testmgr.h | 279
Add test vectors for the use of the EBOIV template with cbc(aes)
modes as it is being used by dm-crypt for BitLocker support.
Vectors taken from dm-crypt test suite images.
Signed-off-by: Gilad Ben-Yossef
---
crypto/tcrypt.c | 9 ++
crypto/testmgr.c | 6 +
crypto/testmgr.h | 279
From: Eric Biggers
Currently, by default crypto self-test failures only result in a
pr_warn() message and an "unknown" status in /proc/crypto. Both of
these are easy to miss. There is also an option to panic the kernel
when a test fails, but that can't be the default behavior.
Add test vectors for the use of the EBOIV template with cbc(aes)
modes as it is being used by dm-crypt for BitLocker support.
Vectors taken from dm-crypt test suite images.
Signed-off-by: Gilad Ben-Yossef
---
crypto/tcrypt.c | 9 ++
crypto/testmgr.c | 6 +
crypto/testmgr.h | 279
NIST SP800-90B requires an implementation of the "Adaptive Proportion"
health test (APT) or similar for detecting noise source entropy
degradations.
This tests works by counting how many times the first sample value in a
sequence of n events occurs among the remaining n-1 samples. The
The startup health tests to be executed at boot as required by NIST 800-90B
consist of running the contiuous health tests, i.e. the Adaptive Proportion
Test (APT) and the Repetition Count Test (RCT), until a certain amount
of noise samples have been examined. In case of test failure during this
estimated entropy must not get added to the global input_pool balance, but
queued up at the fast_pool's queued_entropy instance. Once the health test
have eventually succeeded, as indiciated by health_test_process(), the
entropy previously queued up may get dispatched to the global reserve.
OTOH,
The "Repetition Count Test" (RCT) as specified by NIST SP800-90B simply
counts the number of times the same sample value has been observed and
reports failure if an highly unlikely threshold is exceeded. The exact
values of the latter depend on the estimated per-IRQ min-entropy H as well
reject in case this hypothesis turns out to be wrong, i.e. if the
actual min-entropy is smaller. As long as the startup tests haven't
finished, entropy dispatch and thus, the initial crng seeding, is
inhibited. On test failure, the startup tests would restart themselves
from the beginning.
It fo
achieve the test purpose.
Signed-off-by: Tianjia Zhang
Tested-by: Xufeng Zhang
---
crypto/testmgr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 23c27fc96394..cd002a030af5 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
Add testmgr test vectors for SM2 algorithm. These vectors come
from `openssl pkeyutl -sign` and libgcrypt.
Signed-off-by: Tianjia Zhang
Tested-by: Xufeng Zhang
---
crypto/testmgr.c | 6 +
crypto/testmgr.h | 59
2 files changed, 65
c_size to be empty, skip
the comparison of the ciphertext, and compare the decrypted
plaintext with m to achieve the test purpose.
Signed-off-by: Tianjia Zhang
Tested-by: Xufeng Zhang
---
crypto/testmgr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Is there supposed to be
pty, skip
> the comparison of the ciphertext, and compare the decrypted
> plaintext with m to achieve the test purpose.
>
> Signed-off-by: Tianjia Zhang
> Tested-by: Xufeng Zhang
> ---
> crypto/testmgr.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Is there sup
From: Ayush Sawal
[ Upstream commit 9195189e00a7db55e7d448cee973cae87c5a3c71 ]
The libkcapi test which causes kernel panic is
aead asynchronous vmsplice multiple test.
./bin/kcapi -v -d 4 -x 10 -c "ccm(aes)"
-q 4edb58e8d5eb6bc711c43a6f3693daebde2e5524f1b55297abb29f003236e43d
-t a
From: Ayush Sawal
[ Upstream commit 9195189e00a7db55e7d448cee973cae87c5a3c71 ]
The libkcapi test which causes kernel panic is
aead asynchronous vmsplice multiple test.
./bin/kcapi -v -d 4 -x 10 -c "ccm(aes)"
-q 4edb58e8d5eb6bc711c43a6f3693daebde2e5524f1b55297abb29f003236e43d
-t a
achieve the test purpose.
Signed-off-by: Tianjia Zhang
Tested-by: Xufeng Zhang
---
crypto/testmgr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 23c27fc96394..cd002a030af5 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
Hi Stephen,
It worked, thank you so much
Regards,
Jaya
-Original Message-
From: Stephan Mueller
Sent: Monday, August 24, 2020 9:00 PM
To: linux-crypto@vger.kernel.org; Bhat, Jayalakshmi Manjunath
Subject: Re: HMAC test fails for big key using libkcapi
Am Montag, 24. August 2020, 16
Am Montag, 24. August 2020, 16:41:13 CEST schrieb Bhat, Jayalakshmi Manjunath:
Hi Jayalakshmi,
> Hi All,
>
> I am using libkcapi to execute HMAC tests. One of key size is 229248 bytes.
> setsockopt(tfmfd, SOL_ALG, ALG_SET_KEY API fails to set the key. I am not
> getting an option to set the buf
Hi All,
I am using libkcapi to execute HMAC tests. One of key size is 229248 bytes.
setsockopt(tfmfd, SOL_ALG, ALG_SET_KEY API fails to set the key.
I am not getting an option to set the buffer size to higher value.
Can you please provide me inputs on how to set the higher buffer size to sock
achieve the test purpose.
Signed-off-by: Tianjia Zhang
---
crypto/testmgr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6863f911fcee..0dc94461c437 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -4025,7 +4025,7 @@ static
achieve the test purpose.
Signed-off-by: Tianjia Zhang
---
crypto/testmgr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6863f911fcee..0dc94461c437 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -4025,7 +4025,7 @@ static
crypto test module passes zero length vectors as test input to sha-1 and
sha-256. To provide correct output for these vectors, hash zero support
has been added as in other crypto drivers.
Signed-off-by: Sivaprakash Murugesan
---
drivers/crypto/Kconfig | 2 ++
drivers/crypto/qce/common.h
achieve the test purpose.
Signed-off-by: Tianjia Zhang
---
crypto/testmgr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6863f911fcee..0dc94461c437 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -4025,7 +4025,7 @@ static
From: Pooja Trivedi
Date: Fri, 5 Jun 2020 16:01:18 +
> This selftest tests for cases where sendfile's 'count'
> parameter is provided with a size greater than the intended
> file size.
>
> Motivation: When sendfile is provided with 'count' parameter
> value that is greater than the size of
From: Devulapally Shiva Krishna
[ Upstream commit 10b0c75d7bc19606fa9a62c8ab9180e95c0e0385 ]
The ccm(aes) test fails when req->assoclen > ~240bytes.
The problem is the value assigned to auth_offset is wrong.
As auth_offset is unsigned char, it can take max value as 255.
So fix it by mak
From: Nicolas Toromanoff
[ Upstream commit a8cc3128bf2c01c4d448fe17149e87132113b445 ]
Fix wrong crc32 initialisation value:
"alg: shash: stm32_crc32 test failed (wrong result) on test vector 0,
cfg="init+update+final aligned buffer"
cra_name="crc32c" expects an
From: Devulapally Shiva Krishna
[ Upstream commit 10b0c75d7bc19606fa9a62c8ab9180e95c0e0385 ]
The ccm(aes) test fails when req->assoclen > ~240bytes.
The problem is the value assigned to auth_offset is wrong.
As auth_offset is unsigned char, it can take max value as 255.
So fix it by mak
From: Nicolas Toromanoff
[ Upstream commit a8cc3128bf2c01c4d448fe17149e87132113b445 ]
Fix wrong crc32 initialisation value:
"alg: shash: stm32_crc32 test failed (wrong result) on test vector 0,
cfg="init+update+final aligned buffer"
cra_name="crc32c" expects an
From: Devulapally Shiva Krishna
[ Upstream commit 10b0c75d7bc19606fa9a62c8ab9180e95c0e0385 ]
The ccm(aes) test fails when req->assoclen > ~240bytes.
The problem is the value assigned to auth_offset is wrong.
As auth_offset is unsigned char, it can take max value as 255.
So fix it by mak
From: Devulapally Shiva Krishna
[ Upstream commit 10b0c75d7bc19606fa9a62c8ab9180e95c0e0385 ]
The ccm(aes) test fails when req->assoclen > ~240bytes.
The problem is the value assigned to auth_offset is wrong.
As auth_offset is unsigned char, it can take max value as 255.
So fix it by mak
From: Nicolas Toromanoff
[ Upstream commit a8cc3128bf2c01c4d448fe17149e87132113b445 ]
Fix wrong crc32 initialisation value:
"alg: shash: stm32_crc32 test failed (wrong result) on test vector 0,
cfg="init+update+final aligned buffer"
cra_name="crc32c" expects an
On Fri, 5 Jun 2020 16:01:18 + Pooja Trivedi wrote:
> This selftest tests for cases where sendfile's 'count'
> parameter is provided with a size greater than the intended
> file size.
>
> Motivation: When sendfile is provided with 'count' parameter
> value that is greater than the size of the
This selftest tests for cases where sendfile's 'count'
parameter is provided with a size greater than the intended
file size.
Motivation: When sendfile is provided with 'count' parameter
value that is greater than the size of the file, kTLS example
fails to send the file correctly. Last chunk of t
On Tue, Jun 2, 2020 at 3:19 PM Jakub Kicinski wrote:
>
> On Tue, 2 Jun 2020 14:56:25 + Pooja Trivedi wrote:
> > This selftest tests for cases where sendfile's 'count'
> > parameter is provided with a size greater than the intended
> > file size.
> >
> > Motivation: When sendfile is provided w
1 - 100 of 946 matches
Mail list logo
