Verified, still open: explicitely checked for 1.0.1-beta2 and 1.0.0g,
code in trunk is the same. 0.9.8 doesn't contain the problematic parts.
The define _POSIX_C_SOURCE 2 was added in
http://cvs.openssl.org/chngview?cn=14636
and slightly improved in
http://cvs.openssl.org/chngview?cn=18152
HT processors are a nightmare for security yes :). You are assuming the target software is collecting data continuously as fast as it can - which I agree, simply turns it into the designated victim :). Don't do that - the data rate it high enough you can sample on demand and you can afford some
Sparc assembler warning
/usr/ccs/bin/as: sha512-sparcv9.s, line 676: warning: v8+ ABI
violation: illegal use of %i or %l register as rs1 in brnz,a instruction
on Solaris.
Fixed in trunk, please backport
http://cvs.openssl.org/chngview?cn=22016
to 1.0.1 and 1.0.0.
Regards,
Rainer
Warning when building 1.0.1-beta2:
Use of uninitialized value $output in pattern match (m//) at
asm/md5-x86_64.pl line 115.
Code looks like:
111 my $flavour = shift;
112 my $output = shift;
113 if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
114
115 my $win64=0; $win64=1 if
HT processors are a nightmare for security yes :).
I've attempted the experiment even on hyper-threading P4. No anomalies
in sense that it looks pretty much like another P4. Well, one thread
appears to get more interrupts, while spikes tend to be higher on the
other thread. But when it comes to
Well, if you had say a single thread collecting data to feed an entropy
pool, once an attacker syncronized on that, they'd win. Not sure that's
possible, but it's probably better for security if this is done inline by
each thread as needed. (Particularly when you consider the real OpenSSL
usage
