On Fri, Oct 23, 2020 at 03:27:48PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> One of the assignments that was removed by commit 4a0c1de64bf9 ("crypto:
> x86/poly1305 - Remove assignments with no effect") is actually needed,
> since it affects the return value.
>
> This fixes the followi
On Fri, Oct 23, 2020 at 03:22:02PM -0400, Arvind Sankar wrote:
> This reduces code size substantially (on x86_64 with gcc-10 the size of
> sha256_update() goes from 7593 bytes to 1952 bytes including the new
> SHA256_K array), and on x86 is slightly faster than the full unroll
> (tested on Broadwel
From: Eric Biggers
One of the assignments that was removed by commit 4a0c1de64bf9 ("crypto:
x86/poly1305 - Remove assignments with no effect") is actually needed,
since it affects the return value.
This fixes the following crypto self-test failure:
alg: shash: poly1305-simd test failed (wro
On Fri, Oct 23, 2020 at 03:22:00PM -0400, Arvind Sankar wrote:
> The assignments to clear a through h and t1/t2 are optimized out by the
> compiler because they are unused after the assignments.
>
> Clearing individual scalar variables is unlikely to be useful, as they
> may have been assigned to
On Sat, Oct 24, 2020 at 07:45:36AM +1100, Herbert Xu wrote:
> On Fri, Oct 23, 2020 at 08:56:04AM -0700, Eric Biggers wrote:
> >
> > When clearing memory because "it may be sensitive" rather than "it's needed
> > for
> > the code to behave correctly", I think it's best to use memzero_explicit()
>
On Fri, Oct 23, 2020 at 03:21:59PM -0400, Arvind Sankar wrote:
> Without the barrier_data() inside memzero_explicit(), the compiler may
> optimize away the state-clearing if it can tell that the state is not
> used afterwards. At least in lib/crypto/sha256.c:__sha256_final(), the
> function can get
On Fri, Oct 23, 2020 at 08:56:04AM -0700, Eric Biggers wrote:
>
> When clearing memory because "it may be sensitive" rather than "it's needed
> for
> the code to behave correctly", I think it's best to use memzero_explicit() to
> make the intent clear, even if it seems that memset() is sufficient.
Without the barrier_data() inside memzero_explicit(), the compiler may
optimize away the state-clearing if it can tell that the state is not
used afterwards. At least in lib/crypto/sha256.c:__sha256_final(), the
function can get inlined into sha256(), in which case the memset is
optimized away.
Si
Unrolling the LOAD and BLEND loops improves performance by ~8% on x86_64
(tested on Broadwell Xeon) while not increasing code size too much.
Signed-off-by: Arvind Sankar
Reviewed-by: Eric Biggers
---
lib/crypto/sha256.c | 24
1 file changed, 20 insertions(+), 4 deletion
Patch 1 -- Use memzero_explicit() instead of structure assignment/plain
memset() to clear sensitive state.
Patch 2 -- Currently the temporary variables used in the generic sha256
implementation are cleared, but the clearing is optimized away due to
lack of compiler barriers. Drop the clearing.
Th
The assignments to clear a through h and t1/t2 are optimized out by the
compiler because they are unused after the assignments.
Clearing individual scalar variables is unlikely to be useful, as they
may have been assigned to registers, and even if stack spilling was
required, there may be compiler
This reduces code size substantially (on x86_64 with gcc-10 the size of
sha256_update() goes from 7593 bytes to 1952 bytes including the new
SHA256_K array), and on x86 is slightly faster than the full unroll
(tested on Broadwell Xeon).
Signed-off-by: Arvind Sankar
---
lib/crypto/sha256.c | 174
The temporary W[] array is currently zeroed out once every call to
sha256_transform(), i.e. once every 64 bytes of input data. Moving it to
sha256_update() instead so that it is cleared only once per update can
save about 2-3% of the total time taken to compute the digest, with a
reasonable memset(
Hi Konrad,
On Fri, Oct 23, 2020 at 01:55:13PM +0200, Konrad Dybcio wrote:
> Hi,
>
> I was investigating Qualcomm Crypto Engine support on my sdm630
> smartphone and found out that the already-present driver is
> compatible. In meantime I found two issues:
>
> 1. The driver doesn't seem to have a
On Fri, Oct 23, 2020 at 11:39:27AM -0400, Arvind Sankar wrote:
> On Wed, Oct 21, 2020 at 09:36:33PM -0700, Eric Biggers wrote:
> > On Tue, Oct 20, 2020 at 04:39:52PM -0400, Arvind Sankar wrote:
> > > Without the barrier_data() inside memzero_explicit(), the compiler may
> > > optimize away the stat
On Wed, Oct 21, 2020 at 09:36:33PM -0700, Eric Biggers wrote:
> On Tue, Oct 20, 2020 at 04:39:52PM -0400, Arvind Sankar wrote:
> > Without the barrier_data() inside memzero_explicit(), the compiler may
> > optimize away the state-clearing if it can tell that the state is not
> > used afterwards. At
Hi,
I was investigating Qualcomm Crypto Engine support on my sdm630
smartphone and found out that the already-present driver is
compatible. In meantime I found two issues:
1. The driver doesn't seem to have a maintainer? drivers/crypto/qce
doesn't seem to exist in the MAINTAINERS file..
2. The p
17 matches
Mail list logo
