在 2021/2/24 18:15, tudor.amba...@microchip.com 写道:
On 2/24/21 3:29 AM, yumeng wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
在 2021/2/23 18:44, tudor.amba...@microchip.com 写道:
Hi,
On 2/23/21 9:10 AM, Meng Yu wrote:
--- a/drivers/crypto/a
On 2/11/21 3:01 PM, Thara Gopinath wrote:
This patch series is a result of running kernel crypto fuzz tests (by
enabling CONFIG_CRYPTO_MANAGER_EXTRA_TESTS) on the transformations
currently supported via the Qualcomm crypto engine on sdm845. The first
nine patches are fixes for various regress
On Tue, Feb 23, 2021 at 4:54 PM Dey, Megha wrote:
>
> Hi Andy,
>
> On 1/24/2021 8:23 AM, Andy Lutomirski wrote:
> > On Fri, Jan 22, 2021 at 11:29 PM Megha Dey wrote:
> >> Optimize crypto algorithms using AVX512 instructions - VAES and VPCLMULQDQ
> >> (first implemented on Intel's Icelake client a
On Wed, 24 Feb 2021 at 17:29, Josh Poimboeuf wrote:
>
> Standardize the crypto asm to make it resemble compiler-generated code,
> so that objtool can understand it.
>
> This magically enables ORC unwinding from crypto code. It also fixes
> the last known remaining objtool warnings on vmlinux.o, f
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha1_avx2_x86_64_asm.S | 8
1 file changed, 4 insertions(+), 4 de
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha512-ssse3-asm.S | 41 ++
1 file changed, 19
A conditional stack allocation violates traditional unwinding
requirements when a single instruction can have differing stack layouts.
There's no benefit in allocating the stack buffer conditionally. Just
do it unconditionally.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/camellia-aesni-a
Now that all the stack alignment prologues have been cleaned up in the
crypto code, enable objtool. Among other benefits, this will allow ORC
unwinding to work.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/crypto/Makefi
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha512-avx2-asm.S | 42 +++
1 file changed, 20
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha512-avx-asm.S | 41 +++-
1 file changed, 19
Fix register usage comments to match reality.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S
b/arch/x86/crypto/aesni-intel_avx-x86_64.S
index 4fdf3
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha256-avx2-asm.S | 13 ++---
1 file changed, 6 insertions(+), 7 d
These macros are no longer used; remove them.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 8
1 file changed, 8 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S
b/arch/x86/crypto/aesni-intel_avx-x86_64.S
index 2cf8e94d986a..4fdf38e92d5
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha1_ni_asm.S | 8
1 file changed, 4 insertions(+), 4 deletions(-
Objtool detection of asm jump tables would normally just work, except
for the fact that asm retpolines use alternatives. Objtool thinks the
alternative code path (a jump to the retpoline) is a sibling call.
Don't treat alternative indirect branches as sibling calls when the
original instruction h
Simplify the jump table code so that it resembles a compiler-generated
table.
This enables ORC unwinding by allowing objtool to follow all the
potential code paths.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/crc32c-pcl-intel-asm_64.S | 7 ++-
1 file changed, 2 insertions(+), 5 deleti
Use RBP instead of R14 for saving the old stack pointer before
realignment. This resembles what compilers normally do.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 10 --
Standardize the crypto asm to make it resemble compiler-generated code,
so that objtool can understand it.
This magically enables ORC unwinding from crypto code. It also fixes
the last known remaining objtool warnings on vmlinux.o, for LTO and
more.
Josh Poimboeuf (13):
objtool: Support asm ju
* Jari Ruusu wrote:
> loop-AES changes since previous release:
> - Worked around kernel interface changes on 5.11 kernels
thank you!
--
left blank, right bald
loop-AES changes since previous release:
- Worked around kernel interface changes on 5.11 kernels
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7t.tar.bz2
md5sum 974a0705207d97772b8c1388c43aee58
http://loop-aes.sourceforge.net/loop-AES/loop-AE
On 2/24/21 3:29 AM, yumeng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> 在 2021/2/23 18:44, tudor.amba...@microchip.com 写道:
>> Hi,
>>
>> On 2/23/21 9:10 AM, Meng Yu wrote:
>>> --- a/drivers/crypto/atmel-ecc.c
>>> +++ b/drivers/crypto/atm
Em seg., 22 de fev. de 2021 às 17:26, Stefan Berger
escreveu:
>
> On 2/22/21 12:58 PM, Saulo Alessandre wrote:
> > From: Saulo Alessandre
> >
> > * crypto/asymmetric_keys/x509_cert_parser.c
> >- prepare x509 parser to load nist_secp384r1
> >
> > * crypto/ecc_curve_defs.h
> >- add nist_p38
From: Ard Biesheuvel
[ Upstream commit 303fd3e1c771077e32e96e5788817f025f0067e2 ]
The signed long type used for printing the number of bytes processed in
tcrypt benchmarks limits the range to -/+ 2 GiB, which is not sufficient
to cover the performance of common accelerated ciphers such as AES-NI
From: Ard Biesheuvel
[ Upstream commit 303fd3e1c771077e32e96e5788817f025f0067e2 ]
The signed long type used for printing the number of bytes processed in
tcrypt benchmarks limits the range to -/+ 2 GiB, which is not sufficient
to cover the performance of common accelerated ciphers such as AES-NI
From: Ard Biesheuvel
[ Upstream commit 303fd3e1c771077e32e96e5788817f025f0067e2 ]
The signed long type used for printing the number of bytes processed in
tcrypt benchmarks limits the range to -/+ 2 GiB, which is not sufficient
to cover the performance of common accelerated ciphers such as AES-NI
From: Ard Biesheuvel
[ Upstream commit 303fd3e1c771077e32e96e5788817f025f0067e2 ]
The signed long type used for printing the number of bytes processed in
tcrypt benchmarks limits the range to -/+ 2 GiB, which is not sufficient
to cover the performance of common accelerated ciphers such as AES-NI
On Wed, Feb 24, 2021 at 11:17 AM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of struct bus_type::remove()
> because there is only little that can be done. To simplify the quest to
> make this function return void, let struct vio_driver::remove() return
> void, too. All us
Hi Randy,
On Mon, Feb 22, 2021 at 08:48:42AM -0800, Randy Dunlap wrote:
> Hi,
>
> On 2/21/21 10:42 PM, Lee, Chun-Yi wrote:
> > Add an openssl command option example for generating CodeSign extended
> > key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled.
> >
> > Signed-off-by: "Lee, Chu
BCM6368 devices need to reset the in order to generate true random numbers.
This is what BCM6368 produces without a reset:
root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000
rngtest 6.10
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. T
Some devices may need to perform a reset before using the RNG, such as the
BCM6368.
Signed-off-by: Álvaro Fernández Rojas
---
v4: pass dt_binding_check.
v3: make resets required if brcm,bcm6368-rng.
v2: document reset support.
.../devicetree/bindings/rng/brcm,bcm2835.yaml | 14 +
v4: fix documentation, add reset_control_rearm().
v3: make resets required if brcm,bcm6368-rng.
v2: document reset support.
Álvaro Fernández Rojas (2):
dt-bindings: rng: bcm2835: document reset support
hwrng: bcm2835: add reset support
.../devicetree/bindings/rng/brcm,bcm2835.yaml | 14
31 matches
Mail list logo
