On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote:
>
> - correlation: the interrupt noise source is closely correlated to the HID/
> block noise sources. I see that the fast_pool somehow "smears" that
> correlation. However, I have not seen a full assessment that the correlation
>
On Fri, 2016-08-12 at 06:28 -0400, Xiaodong Liu wrote:
> Signed-off-by: Xiaodong Liu
> ---
> arch/x86/crypto/sha512-mb/sha512_mb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c
>
On Fri, 2016-08-12 at 06:24 -0400, Xiaodong Liu wrote:
> 1. fix ctx pointer
> Use req_ctx which is the ctx for the next job that have
> been completed in the lanes instead of the first
> completed job rctx, whose completion could have been
> called and released.
> 2. fix digest copy
> Use XMM
Am Donnerstag, 11. August 2016, 21:55:05 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hello,
>
> A few algorithms are failing Œalg self tests' during kernel boot into FIPS
> mode (fips=1), causing a kernel panic (see below). I am using vanilla
> kernel-4.7 source for these tests.
>
> These messages
Signed-off-by: Xiaodong Liu
---
arch/x86/crypto/sha512-mb/sha512_mb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c
b/arch/x86/crypto/sha512-mb/sha512_mb.c
index f4cf5b7..d210174 100644
---
1. fix ctx pointer
Use req_ctx which is the ctx for the next job that have
been completed in the lanes instead of the first
completed job rctx, whose completion could have been
called and released.
2. fix digest copy
Use XMM register to copy another 16 bytes sha256 digest
instead of a regular
Am Donnerstag, 11. August 2016, 17:36:32 CEST schrieb Theodore Ts'o:
Hi Theodore,
> On Thu, Aug 11, 2016 at 02:24:21PM +0200, Stephan Mueller wrote:
> > The following patch set provides a different approach to /dev/random
which
> > I call Linux Random Number Generator (LRNG) to collect entropy
Am Donnerstag, 11. August 2016, 19:42:54 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Hi Stephan,
>
> Any other ideas about this problem ? Since XTS is not amongst the
> self-tests as you observed, is it safe to disable .fips_allowed for
> xts(aes) in testmgr.c ?
If you do that, none of your XTS