Opened 9 years ago

Last modified 7 years ago

#1194 closed defect (Not a bug)

crypto_rand_uint64: Assertion max > 0 failed

Reported by: cygeus Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.1.21
Severity: Keywords:
Cc: cygeus, Sebastian, nickm, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm running tor-0.2.1.21 on an embedded device, a Sagem F@st 3464 modem/router.
some specs:
busybox-1.15.3
uclibc-0.9.26
libevent-1.4.12
openssl-0.9.8l

When starting tor it always fails with following error message:

[err] Bug: crypto.c:1876: crypto_rand_uint64: Assertion max > 0 failed; aborting.

Is there anything I can do to locate the problem?

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Attachments (6)

debug.log (311.7 KB) - added by cygeus 9 years ago.
debug log
tor_unit_tests.log (3.0 KB) - added by cygeus 9 years ago.
tor unit tests
debug_client.log.gz (524.8 KB) - added by cygeus 9 years ago.
debug log when running as a client only
calc.c (1.8 KB) - added by cygeus 9 years ago.
test program with some 32 and 64 bit math
config.log (489.8 KB) - added by cygeus 9 years ago.
config.log generated by configure
configure_output.log (11.1 KB) - added by cygeus 9 years ago.
stdout output of configure

Download all attachments as: .zip

Change History (25)

comment:1 Changed 9 years ago by Sebastian

As a first thing that would be helpful to know, do the unit tests pass?
Also, can you please provide a full debug log, if you can get that on
your device?

Changed 9 years ago by cygeus

Attachment: debug.log added

debug log

Changed 9 years ago by cygeus

Attachment: tor_unit_tests.log added

tor unit tests

comment:2 Changed 9 years ago by cygeus

I've attached the debug log and the results of the unit tests as requested. All unit tests pass, except one. But that is fixed now (missing /etc/hosts).

comment:3 Changed 9 years ago by Sebastian

fun. So we can establish circuits, but as soon as we try to measure our
bandwidth, we explode because we can't pick the first hop.

Does Tor work if you use it as a client only, or does the same error
occur after some time?

Changed 9 years ago by cygeus

Attachment: debug_client.log.gz added

debug log when running as a client only

comment:4 Changed 9 years ago by cygeus

Does Tor work if you use it as a client only, or does the same error
occur after some time?

Running as a client only works, I can browse the web. But after a while
tor crashes with the same error. I had to gzip the debug log because an
error occurred while uploading.

comment:5 Changed 9 years ago by arma

See also bug 1139. Not sure if it's related or not.

comment:6 Changed 9 years ago by nickm

A stack trace would be very useful here.

comment:7 Changed 9 years ago by Sebastian

More input from kenobi on #tor:

kenobi| Scenario for exploiting of 1194 bug with any working good

float-point arithmetics hardware:

kenobi| Launch solid (speed, stability) non-exit relay and wait till it

become Guard (auth believes self adv bw for such desicions).
Than change exit policy to one unique rule over all network
so relay still non-exit. With a little patience wait till measured
bw by auths is 1 (which client used while weight speed

kenobi| s relays).
kenobi| Evil part: place link with address permitted by our guard to

our victim, and will wait till client crash. profit for classic
intersection attack with limit capables.

*kenobi missed kb, but func still with sharp edges and waits of the self exploiter.

[Edited by arma -- this is a separate bug that I've added here:
https://bugs.torproject.org/flyspray/index.php?do=details&id=1203 ]

comment:8 Changed 9 years ago by arma

From the debug log:

Jan 01 17:16:54.620 [debug] smartlist_choose_by_bandwidth(): Total
weighted bw = 317000, exit bw = 591169000, nonexit bw = 5265000,
exit weight = 1.000000 (for exit == 1), guard bw = 421027000, nonguard
bw = 175407000, guard weight = 0.666667 (for guard == 0)

guard_weight = 1.0 - all_bw/(3.0*guard_bw);

all_bw is 591169000+5265000 = 596434000

so guard_weight = 1 - 596434000/(3.0*421027000) = 0.52779.

Yet your Tor calls it .666667.

There are a bunch of other similar mis-calculations in the debug log too.

Does your FPU return garbage rather than correct calculations?

comment:9 Changed 9 years ago by arma

It's acting like guard_weight = 1 - foo/(3.0*bar) is treating foo and
bar as 1. So weight = 1 - 1/3 = .66667 whenever for_guard is 0. I wonder
why the actual numbers just fall away. Is this box unable to do 64 bit
math operations?

comment:10 Changed 9 years ago by cygeus

I wrote a small C program (see attachments) to test some math operations and
it looks you're wright. All 64 bit operations are totally messed up.

This is the output I got:

uint64_t: 1
uint64_t casted to double: 1.000000
uint64_t casted to double: nan
double: 1.000000
constant float: 1.000000
constant double: 1.000000

sizeof(int): 4
sizeof(float): 4
sizeof(double): 8
sizeof(long int): 4
sizeof(long long int): 8

uint64_t casted to double
all_bw: 1.000000 guard_bw: 1.000000
1 - 596434000/(3.0*421027000) = 0.666667

uint64_t casted to long long int
all_bw: 596434000 guard_bw: 421027000
1 - 596434000/(3.0*421027000) = 0.666667

with int's and float's
1 - 596434000/(3.0*421027000) = 0.527794

Changed 9 years ago by cygeus

Attachment: calc.c added

test program with some 32 and 64 bit math

comment:11 Changed 9 years ago by arma

Can you post the output of "./configure" here along with attaching
the config.log file?

Changed 9 years ago by cygeus

Attachment: config.log added

config.log generated by configure

Changed 9 years ago by cygeus

Attachment: configure_output.log added

stdout output of configure

comment:12 Changed 9 years ago by cygeus

Attached you'll find the requested files.

comment:13 Changed 9 years ago by Sebastian

hrm, your test program and the configure output suggest that your system
claims to handle uint64_t, but clearly it doesn't. Don't think we can really fix
that...

comment:14 Changed 9 years ago by nickm

Looks like uint64_t itself is working fine, but the C compiler or its runtime isn't handling casts from uint64_t or
int64_t to double properly: _every_ uint64_t or int64_t gets treated as being equal to 1.0. How annoying and stupid!

My first suggestion is to say, "try to see if there's a patch or an upgrade for your compiler or your runtime."
One is broken. If you have a minimal testcase, you should be able to get the compiler maintainers to pay attention.
If you can read the assembly code for your target platform, I'd suggest you look at the output of
lx4189-uclibc-gcc -S convert.c, where convert.c is a nice simple:

double ull_to_double(unsigned long long ull)
{

return (double) ull;

}

If you confirm that this function doesn't work for reasonably big ull values, you should report a bug to the compiler
maintainers.

My second suggestion is, find a workaround if you can. If you can find a way to reliably convert from uint64_t to
double on your platform, we could add it as another definition of U64_TO_DBL in src/common/compat.h. We haven't
been using that macro as religiously as we should, so we might want to patch the code in circuitbuild to use it.
(We ran into a problem like this before that uint64_t-to-double conversion fail on older versions of MSVC.)

comment:16 Changed 9 years ago by nickm

That's a good link. Later in the thread, the guy seems to have found a solution to his problem:

http://lists.busybox.net/pipermail/uclibc/2007-February/038317.html

comment:17 Changed 9 years ago by arma

Going to close this task as 'not a Tor bug'. It doesn't look like we've heard
from anybody else with the problem, so it isn't worth leaving it open to catch
duplicates.

comment:18 Changed 9 years ago by arma

flyspray2trac: bug closed.

comment:19 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.