Project

General

Profile

Feature #7102

Evaluate how safe haveged is in a virtualized environment

Added by intrigeri over 3 years ago. Updated 9 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
04/17/2014
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Security Audit
Blueprint:
Easy:
No
Affected tool:

Description

haveged relies on the RDTSC instruction, that apparently is useless in "some" virtualized environments:

We should research this further. A good question would be: would we be better off if we did not ship haveged at all, and instead relied only on the standard Linux entropy gathering method (that also likely has flaws when used in a VM)?


Related issues

Related to Tails - Feature #5650: rngd Resolved
Related to Tails - Feature #6116: Audit random seed Confirmed
Related to Tails - Feature #10779: Start haveged earlier in the boot process Resolved 12/20/2015

History

#1 Updated by intrigeri over 3 years ago

#2 Updated by intrigeri over 3 years ago

  • Assignee set to geb

#3 Updated by intrigeri over 3 years ago

#4 Updated by BitingBird almost 3 years ago

geb, do you still plan to audit that ? If yes, that's great - if not, please remove yourself from assignee :)

#5 Updated by intrigeri over 2 years ago

  • Description updated (diff)

#6 Updated by intrigeri over 2 years ago

David Goulet wrote on #5650#note-16:

There is a fallback usually to rdtsc. In haveged case, the generic fallback is:

clock_gettime(CLOCK_MONOTONIC, &ts);

The monotonic clock is used. It can NOT go back in time but might subject to incremental adjustement by any NTP correction. Still much better than using "date +%s".

#7 Updated by intrigeri over 2 years ago

  • Assignee changed from geb to intrigeri
  • Target version set to Tails_1.4

I'll try to take care of it for 1.4.

#8 Updated by intrigeri over 2 years ago

  • Target version changed from Tails_1.4 to Hole in the Roof

#9 Updated by intrigeri over 2 years ago

  • Assignee deleted (intrigeri)

It's unlikely that I'll have+take time to take care of this. Anyone else, feel free to take it.

#10 Updated by intrigeri almost 2 years ago

  • Related to Feature #10779: Start haveged earlier in the boot process added

#11 Updated by intrigeri over 1 year ago

  • Type of work changed from Audit to Security Audit

#12 Updated by intrigeri over 1 year ago

  • Description updated (diff)

#13 Updated by cypherpunks over 1 year ago

One solution would be to have haveged XOR its contents with the pool without issuing the ioctls to raise the pool's entropy estimate. This can be done by writing constantly to the pool through the randomness device, such as by running the following in the background at start up:

haveged -n 0 -f - 2>/dev/null | pv -q -L 1024 >/dev/urandom

This will write to /dev/urandom at a rate of 1024 bytes per second (I think it actually writes it in bursts of 4096 or 512 bytes but I really don't remember and I don't have strace on hand right now). The overhead is extremely small even on very low-power netbooks, and should provide far superior randomness to using regular haveged, while additionally not increasing the entropy estimate by itself.

An alternative would be to write to /dev/urandom in chunks every 10 minutes or so, by adding something like this to a cron job:

haveged -n 1M -f /dev/urandom 2>/dev/null

That won't provide the same recovery speed against PRNG state compromises, but it will skip the admittedly low overhead of pv.

I would personally recommend using the former. I've used something akin to that for many years. The only downsides I can see for either of these options is with Pidgin's OTR key generation, which by default reads from /dev/urandom, and generating GPG keys, which do the same.

#14 Updated by cypherpunks 9 months ago

intrigeri wrote:

David Goulet wrote on #5650#note-16:

There is a fallback usually to rdtsc. In haveged case, the generic fallback is:

clock_gettime(CLOCK_MONOTONIC, &ts);

The monotonic clock is used. It can NOT go back in time but might subject to incremental adjustement by any NTP correction. Still much better than using "date +%s".

That is only a fallback if TSC support is reported missing by the CPU. In some hypervisors, it doesn't report it missing, instead it traps it and returns NULL in eax and edx. This means haveged falsely thinks it has a working TSC.

I don't think Tails will ever be in a situation where the clock_gettime() fallback is used, because no hypervisor should report a CPU with a missing TSC, and Tails does not support any CPU architectures that genuinely lack a TSC (modern x86 and ARM support it). The only problems that can occur, as far as I know, are Tails being provided with a bogus TSC.

I don't know if this is a problem for the kernel's entropy generator, since it calculates the deltas between three RDTSC invocations before incrementing the entropy estimate in add_timer_entropy(). Someone should test this in bochs.

Also available in: Atom PDF