Re: [uml-devel] /dev/random problems .. or FP registers corruption?! - Openssl
This is a discussion on Re: [uml-devel] /dev/random problems .. or FP registers corruption?! - Openssl ; Hi,
Well, I am now puzzled quite a bit more. Another problem
on this UML box is that if I do tail -f on some file,
I ocassionally get an assertion:
tail: xnanosleep.c:67: xnanosleep: Assertion `0
This seems to happen ...
-
Re: [uml-devel] /dev/random problems .. or FP registers corruption?!
Hi,
Well, I am now puzzled quite a bit more. Another problem
on this UML box is that if I do tail -f on some file,
I ocassionally get an assertion:
tail: xnanosleep.c:67: xnanosleep: Assertion `0 <= seconds' failed.
This seems to happen more often (or at all) when I am
doing something using the openssl - tail -f on an apache
access log runs fine when I am doing http accesses
and fails quite repeatedly when I am doing https
or starting/terminating new SSL connection from/to the box.
I also have a few strace-s from the failing sshd,
where I can't really understand how the code got there.
These two have one thing in common - a double variable
that got initialized long ago and at the time of the
problem it looks like it mysteriously changed value:
"entropy" in the case of openssl and "sleep_interval"
in tail.
Am I seeing ghosts? Anyone got other mysterious
problems with current UML kernel? Could it be that
some state-saving method is corrupting fp registers
or something like that? Was there some change in the
UML / vanilla kernel recently?
To the openssl-ers: I am starting to think that openssl
is fine here and that the problem is indeed in the
UML kernel.
Regards
--
Stano
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org
-
Re: [uml-devel] /dev/random problems .. or FP registers corruption?!
Stanislav Meduna wrote:
> Am I seeing ghosts? Anyone got other mysterious
> problems with current UML kernel? Could it be that
> some state-saving method is corrupting fp registers
> or something like that? Was there some change in the
> UML / vanilla kernel recently?
Confirmed: I can reproduce openssl changing a double
value in unrelated process. I was not able to come
up with a code not relying on external software yet:
===
#include
#include
#include
#include
#include
testdblchg()
{
volatile double x0 = 2.0;
volatile double x1;
int iter = 0;
fprintf(stderr, "Starting loop, pid=%d\n", getpid());
while(1)
{
++iter;
x1 = x0;
x0 += 1.0;
if (x0 != x1 + 1)
{
kill(getppid(), SIGTERM);
fprintf(stderr, "Double variable changed! pid=%d, iteration=%d, should=%g,
is=%g\n", getpid(), iter, x1+1, x0);
exit(1);
}
sleep(1);
}
}
testcrypto()
{
while(1)
{
system("openssl genrsa -out /dev/null 4096");
sleep(1);
}
}
main()
{
if (fork() == 0)
testdblchg();
testcrypto();
}
===
Output:
$ ./a.out
Starting loop, pid=16920
Generating RSA private key, 4096 bit long modulus
.......++
.................................................. .................................................. .................................................. ..................++
e is 65537 (0x10001)
Generating RSA private key, 4096 bit long modulus
....................................Double variable changed! pid=16920, iteration=15,
should=nan, is=nan
Terminated
$ uname -a
Linux dirk 2.6.26 #1 Wed Jul 30 10:56:10 CEST 2008 i686 GNU/Linux
$ cat /proc/cpuinfo
processor : 0
vendor_id : User Mode Linux
model name : UML
mode : skas
host : Linux seldon-base 2.6.23.17 #2 SMP Sat Jun 21 15:04:22 CEST 2008 i686
bogomips : 4771.02
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-2'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-2)
$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii libc6 2.7-10 GNU C Library: Shared libraries
Regards
--
Stano
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org
-
Re: [uml-devel] /dev/random problems .. or FP registers corruption?!
Your test is wrong. NaN != NaN.
/r$
--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org
-
Re: [uml-devel] /dev/random problems .. or FP registers corruption?!
Richard Salz wrote:
> Your test is wrong. NaN != NaN.
My test is right. Please, look into the code and the previous
discussion. The whole point of the test is that the x0/x1 are
mysteriously changed from outside of the process.
The test will run indefinitely (well until precision
suffices) disabling the genrsa. And if I add the
else
{
fprintf(stderr, "\npid=%d, iteration=%d, should=%g, is=%g\n", getpid(), iter, x1+1,
x0);
}
I get the loop counting for a while before bombing out.
Starting loop, pid=16986
pid=16986, iteration=1, should=3, is=3
Generating RSA private key, 4096 bit long modulus
................
pid=16986, iteration=2, should=4, is=4
..++
...............
pid=16986, iteration=3, should=5, is=5
..................
pid=16986, iteration=4, should=6, is=6
......++
e is 65537 (0x10001)
pid=16986, iteration=5, should=7, is=7
Generating RSA private key, 4096 bit long modulus
........
pid=16986, iteration=6, should=8, is=8
..................
pid=16986, iteration=7, should=9, is=9
.................Double variable changed! pid=16986, iteration=8, should=nan, is=nan
Terminated
I am Cc-ing the ssl list because I previously thought it
is an openssl bug - it is not.
Regards
--
Stano
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org