On Tue, 21 May 2013 17:39:49 -0400
Sandy Harris wrote:
Hi Sandy,
> On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o wrote:
>
> > I continue to be suspicious about claims that userspace timing
> > measurements are measuring anything other than OS behaviour.
>
> Yes, but they do seem to contain s
On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o wrote:
> I continue to be suspicious about claims that userspace timing
> measurements are measuring anything other than OS behaviour.
Yes, but they do seem to contain some entropy. See links in the
original post of this thread, the havege stuff and
I continue to be suspicious about claims that userspace timing
measurements are measuring anything other than OS behaviour. But that
doesn't mean that they shouldn't exist. Personally, I believe you
should try to collect as much entropy as you can, from as many places
as you can. For VM's, it me
On Tue, 21 May 2013 12:09:02 -0400
Sandy Harris wrote:
Hi Sandy,
> I very much like the basic notion here. The existing random(4) driver
> may not get enough entropy in a VM or on a device like a Linux router
> and I think work such as yours or HAVEGE (
> http://www.irisa.fr/caps/projects/hipsor
I very much like the basic notion here. The existing random(4) driver
may not get enough entropy in a VM or on a device like a Linux router
and I think work such as yours or HAVEGE
(http://www.irisa.fr/caps/projects/hipsor/) are important research.
The paper by McGuire et al of "Analysis of inheren
Add sha224 implementation to sha256_ssse3 module.
This also fixes sha256_ssse3 module autoloading issue when 'sha224' is used
before 'sha256'. Previously in such case, just sha256_generic was loaded and
not sha256_ssse3 (since it did not provide sha224). Now if 'sha256' was used
after 'sha224' usa
Add sha384 implementation to sha512_ssse3 module.
This also fixes sha512_ssse3 module autoloading issue when 'sha384' is used
before 'sha512'. Previously in such case, just sha512_generic was loaded and
not sha512_ssse3 (since it did not provide sha384). Now if 'sha512' was used
after 'sha384' usa
'sha512_generic' should set driver name now that there is alternative sha512
provider (sha512_ssse3).
Signed-off-by: Jussi Kivilinna
---
crypto/sha512_generic.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/sha512_generic.c b/crypto/sha512_generic.c
index 4c58620..6ed124f 10064
The _XFER stack element size was set too small, 8 bytes, when it needs to be
16 bytes. As _XFER is the last stack element used by these implementations,
the 16 byte stores with 'movdqa' corrupt the stack where the value of register
%r12 is temporarily stored. As these implementations align the stac
On Mon, May 20, 2013 at 12:09:45PM -0700, Tim Chen wrote:
> On Mon, 2013-05-20 at 19:47 +0800, Herbert Xu wrote:
>
> >
> > Nope this is still broken. We need to move the actual crct10dif
> > code into crypto/. I'll fix up the patch in the tree.
> >
> > Also I'm going to get rid of crc_t10dif_u
10 matches
Mail list logo