Re: Trouble with /dev/urandom

2016-10-27 Thread Nadav Har'El 
On Fri, Oct 14, 2016 at 9:55 PM, Raphael Carvalho 
wrote:

>
>
> On Fri, Oct 14, 2016 at 11:59 AM, Tomasz Grabiec 
> wrote:
>
>>
>>
>> On Fri, Oct 14, 2016 at 4:56 PM, Raphael Carvalho > > wrote:
>>
>>>
>>>
>>> On Fri, Oct 14, 2016 at 10:39 AM, Benoît Canet <
>>> ben...@cloudius-systems.com> wrote:
>>>

 Hello list,

 In the process of porting go to OSv I noticed that the Go runtime
 initialization stall half the time waiting in a read for /dev/urandom.

 The message OSv output is "random: blocking on read.".

 It then sometime proceeed to unblock itself a couple dozen of seconds
 later.

 Does it ring a bell ? Is it expected behavior from /dev/urandom ?

>>>
>>> manpage:
>>> "A read from the /dev/urandom device will not block waiting for more
>>> entropy.  If there is not sufficient entropy, a pseudorandom number
>>> generator is used to  create the  requested  bytes.   As  a result, in this
>>> case the returned values are theoretically vulnerable to a cryptographic
>>> attack on the algorithms used by the driver."
>>>
>>> In our impl, /dev/urandom and /dev/random are both pointing to the same
>>> mechanism to generate random numbers, and that means they both can block.
>>> We should probably look into doing something for /dev/urandom to match the
>>> behavior described above.
>>>
>>
>> We're using BSD's implementation.
>>
>> It has both /dev/random and /dev/urandom unified. It's a PRNG which is
>> periodically reseeded.
>>
>
> Indeed, but we may skip this step 'https://github.com/cloudius-
> systems/osv/blob/master/drivers/random.cc#L65' for
> /dev/urandom. Application expects /dev/urandom not to block waiting for
> entropy, and that should probably be respected. I think we discussed it in
> the past, but I don't remember what we concluded from it.
>
>
I opened https://github.com/cloudius-systems/osv/issues/805 about this.

It's not enough to skip the "have we been seeded yet" check, because if we
haven't been seeded, we'll get a constant seed and unacceptable quality
(predictable) random numbers. We need to generate some entropy during boot
(should be possible - we have interrupt timings, packet timings, disk
timings, as well as higher level but low-entropy events like at what
nanosecond time we start the application, etc.) so we'll have some seed
very early, even if not the high quality one we can get from the host's
entropy.

A cop-out solution can be to also just use the seed of nanotime() if no
other seed is yet available, similar to the classic srand(time(0)) idiom.
This is a cop-out because this is a low quality seed (the adversary can
guess a relatively small range of possible seeds).

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trouble with /dev/urandom

2016-10-14 Thread Benoît Canet 
Thanks I will dig this.

On Fri, Oct 14, 2016 at 4:29 PM, Tomasz Grabiec 
wrote:

>
>
> On Fri, Oct 14, 2016 at 4:14 PM, Benoît Canet  > wrote:
>
>>
>> QEMU on ubuntu 16.04.
>>
>> benoit@alfred:~/osv$ cat /proc/sys/kernel/random/entropy_avail
>>
>> 58
>>
>>
> That's not a lot.  Try watching it during your test.
>
>
>> Some go debugging interleaved.
>>
>> OSv v0.24-199-g733d26f
>> 4 CPUs detected
>> Firmware vendor: SeaBIOS
>> bsd: initializing - done
>> VFS: mounting ramfs at /
>> VFS: mounting devfs at /dev
>> net: initializing - done
>> vga: Add VGA device instance
>> eth0: ethernet address: 52:54:00:12:34:56
>> virtio-blk: Add blk device instances 0 as vblk0, devsize=10737418240
>> random: virtio-rng registered as a source.
>> random: intel drng, rdrand registered as a source.
>>
>>
> Looks like we have both virtio-rng and drng registered as entropy sources.
>
> There is a thread which polls them 10 times a second. See random_kthread()
> from random_harvestq.cc. It feeds entropy into the system via
> random_process_event() from yarrow.cc. Maybe we're not replenishing entropy
> fast enough. Check if and which live sources provide entropy. Try
> increasing the rate.
>
> random:  initialized
>> VFS: unmounting /dev
>> VFS: mounting zfs at /zfs
>> zfs: mounting osv/zfs from device /dev/vblk0.1
>> VFS: mounting devfs at /dev
>> VFS: mounting procfs at /proc
>> program zpool.so returned 1
>> BSD shrinker: event handler list found: 0xa1e6ca80
>> BSD shrinker found: 1
>> BSD shrinker: unlocked, running
>> [I/42 dhcp]: Waiting for IP...
>> [I/252 dhcp]: Server acknowledged IP for interface eth0
>> eth0: 192.168.122.15
>> [I/252 dhcp]: Configuring eth0: ip 192.168.122.15 subnet mask 255.255.255.0 
>> gateway 192.168.122.1 MTU 1500
>> args
>> 0
>> 1.5
>> 4.0
>> 6.0
>> 6.5
>> 6.0
>> 6.2
>> 6.1
>> typ != _STT_FUNC %i
>> true 0 bind != _STB_GLOBAL && bind != _STB_WEAK %i
>> falsesym.st_shndx == _SHN_UNDEF %ifalse6.5
>> 6.0
>> 6.5
>> 7
>> osinit
>> schedinit enter
>> schedinit 1
>> schedinit 2
>> schedinit 3
>> schedinit 4
>> schedinit 5
>> schedinit 6
>> schedinit 7
>> schedinit 8
>> alginit 1
>> alginit 2
>> alginit 3
>> getRandomData 1
>> getRandomData 3
>> getRandomData 4
>> random: blocking on read.
>> random: device unblocked.
>> getRandomData 5
>> getRandomData 6
>> getRandomData 7
>> alginit 4
>> schedinit 9
>> schedinit 10
>> schedinit 11
>> schedinit 12
>> schedinit 13
>> schedinit 14
>> schedinit 15
>> schedinit 16
>> schedinit 17
>> schedinit 18
>> schedinit 19
>> schedinit 21
>> schedinit 25
>> schedinit 27
>> schedinit exit
>> newproc enter
>> newproc exit
>> mstart enter
>> sigaltstack() stubbed
>> mstart enter
>> mstart enter
>> newproc enter
>> blub
>>
>> [backtrace]
>> 0x00202525 
>> 0x0032a97a 
>> 0x00388b98 
>> 0x00387a36 
>> 0x1147e0d2 
>> 0x1147f15b 
>> 0x1147c7db 
>> 0x1147c6cc 
>> 0x114cf232 
>> 0x2055ff3f 
>>
>>
>
>
>
>>
>>
>> On Fri, Oct 14, 2016 at 3:57 PM, Tomasz Grabiec 
>> wrote:
>>
>>>
>>>
>>> On Fri, Oct 14, 2016 at 3:39 PM, Benoît Canet <
>>> ben...@cloudius-systems.com> wrote:
>>>

 Hello list,

 In the process of porting go to OSv I noticed that the Go runtime
 initialization stall half the time waiting in a read for /dev/urandom.

 The message OSv output is "random: blocking on read.".

 It then sometime proceeed to unblock itself a couple dozen of seconds
 later.

 Does it ring a bell ? Is it expected behavior from /dev/urandom ?

>>>
>>> It looks like entropy pool was depleted. Maybe no hardware entropy
>>> sources were detected and we were using only slow interrupt entropy
>>> harvesting.
>>>
>>> Another option is that you are using virtio-rng and entropy was depleted
>>> on your host. Check with `cat /proc/sys/kernel/random/entropy_avail`
>>>
>>> Which hypervisor are you running on?
>>>
>>> Can you show your debug console output?
>>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trouble with /dev/urandom

2016-10-14 Thread Tomasz Grabiec 
On Fri, Oct 14, 2016 at 4:14 PM, Benoît Canet 
wrote:

>
> QEMU on ubuntu 16.04.
>
> benoit@alfred:~/osv$ cat /proc/sys/kernel/random/entropy_avail
>
> 58
>
>
That's not a lot.  Try watching it during your test.


> Some go debugging interleaved.
>
> OSv v0.24-199-g733d26f
> 4 CPUs detected
> Firmware vendor: SeaBIOS
> bsd: initializing - done
> VFS: mounting ramfs at /
> VFS: mounting devfs at /dev
> net: initializing - done
> vga: Add VGA device instance
> eth0: ethernet address: 52:54:00:12:34:56
> virtio-blk: Add blk device instances 0 as vblk0, devsize=10737418240
> random: virtio-rng registered as a source.
> random: intel drng, rdrand registered as a source.
>
>
Looks like we have both virtio-rng and drng registered as entropy sources.

There is a thread which polls them 10 times a second. See random_kthread()
from random_harvestq.cc. It feeds entropy into the system via
random_process_event() from yarrow.cc. Maybe we're not replenishing entropy
fast enough. Check if and which live sources provide entropy. Try
increasing the rate.

random:  initialized
> VFS: unmounting /dev
> VFS: mounting zfs at /zfs
> zfs: mounting osv/zfs from device /dev/vblk0.1
> VFS: mounting devfs at /dev
> VFS: mounting procfs at /proc
> program zpool.so returned 1
> BSD shrinker: event handler list found: 0xa1e6ca80
> BSD shrinker found: 1
> BSD shrinker: unlocked, running
> [I/42 dhcp]: Waiting for IP...
> [I/252 dhcp]: Server acknowledged IP for interface eth0
> eth0: 192.168.122.15
> [I/252 dhcp]: Configuring eth0: ip 192.168.122.15 subnet mask 255.255.255.0 
> gateway 192.168.122.1 MTU 1500
> args
> 0
> 1.5
> 4.0
> 6.0
> 6.5
> 6.0
> 6.2
> 6.1
> typ != _STT_FUNC %i
> true 0 bind != _STB_GLOBAL && bind != _STB_WEAK %i
> falsesym.st_shndx == _SHN_UNDEF %ifalse6.5
> 6.0
> 6.5
> 7
> osinit
> schedinit enter
> schedinit 1
> schedinit 2
> schedinit 3
> schedinit 4
> schedinit 5
> schedinit 6
> schedinit 7
> schedinit 8
> alginit 1
> alginit 2
> alginit 3
> getRandomData 1
> getRandomData 3
> getRandomData 4
> random: blocking on read.
> random: device unblocked.
> getRandomData 5
> getRandomData 6
> getRandomData 7
> alginit 4
> schedinit 9
> schedinit 10
> schedinit 11
> schedinit 12
> schedinit 13
> schedinit 14
> schedinit 15
> schedinit 16
> schedinit 17
> schedinit 18
> schedinit 19
> schedinit 21
> schedinit 25
> schedinit 27
> schedinit exit
> newproc enter
> newproc exit
> mstart enter
> sigaltstack() stubbed
> mstart enter
> mstart enter
> newproc enter
> blub
>
> [backtrace]
> 0x00202525 
> 0x0032a97a 
> 0x00388b98 
> 0x00387a36 
> 0x1147e0d2 
> 0x1147f15b 
> 0x1147c7db 
> 0x1147c6cc 
> 0x114cf232 
> 0x2055ff3f 
>
>



>
>
> On Fri, Oct 14, 2016 at 3:57 PM, Tomasz Grabiec 
> wrote:
>
>>
>>
>> On Fri, Oct 14, 2016 at 3:39 PM, Benoît Canet <
>> ben...@cloudius-systems.com> wrote:
>>
>>>
>>> Hello list,
>>>
>>> In the process of porting go to OSv I noticed that the Go runtime
>>> initialization stall half the time waiting in a read for /dev/urandom.
>>>
>>> The message OSv output is "random: blocking on read.".
>>>
>>> It then sometime proceeed to unblock itself a couple dozen of seconds
>>> later.
>>>
>>> Does it ring a bell ? Is it expected behavior from /dev/urandom ?
>>>
>>
>> It looks like entropy pool was depleted. Maybe no hardware entropy
>> sources were detected and we were using only slow interrupt entropy
>> harvesting.
>>
>> Another option is that you are using virtio-rng and entropy was depleted
>> on your host. Check with `cat /proc/sys/kernel/random/entropy_avail`
>>
>> Which hypervisor are you running on?
>>
>> Can you show your debug console output?
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trouble with /dev/urandom

2016-10-14 Thread Benoît Canet 
In the code I don't understand on what the wakeup operate nor on what the
blocking operate.

randomdev_unblock(void)
{
if (!random_context.seeded) {
#ifndef __OSV__
selwakeuppri(_context.rsel, PUSER);
#endif
wakeup(_context);


random_context does not look like a wait condition it look strange.


On Fri, Oct 14, 2016 at 3:57 PM, Tomasz Grabiec 
wrote:

>
>
> On Fri, Oct 14, 2016 at 3:39 PM, Benoît Canet  > wrote:
>
>>
>> Hello list,
>>
>> In the process of porting go to OSv I noticed that the Go runtime
>> initialization stall half the time waiting in a read for /dev/urandom.
>>
>> The message OSv output is "random: blocking on read.".
>>
>> It then sometime proceeed to unblock itself a couple dozen of seconds
>> later.
>>
>> Does it ring a bell ? Is it expected behavior from /dev/urandom ?
>>
>
> It looks like entropy pool was depleted. Maybe no hardware entropy sources
> were detected and we were using only slow interrupt entropy harvesting.
>
> Another option is that you are using virtio-rng and entropy was depleted
> on your host. Check with `cat /proc/sys/kernel/random/entropy_avail`
>
> Which hypervisor are you running on?
>
> Can you show your debug console output?
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trouble with /dev/urandom

2016-10-14 Thread Benoît Canet 
QEMU on ubuntu 16.04.

benoit@alfred:~/osv$ cat /proc/sys/kernel/random/entropy_avail
58

Some go debugging interleaved.

OSv v0.24-199-g733d26f
4 CPUs detected
Firmware vendor: SeaBIOS
bsd: initializing - done
VFS: mounting ramfs at /
VFS: mounting devfs at /dev
net: initializing - done
vga: Add VGA device instance
eth0: ethernet address: 52:54:00:12:34:56
virtio-blk: Add blk device instances 0 as vblk0, devsize=10737418240
random: virtio-rng registered as a source.
random: intel drng, rdrand registered as a source.
random:  initialized
VFS: unmounting /dev
VFS: mounting zfs at /zfs
zfs: mounting osv/zfs from device /dev/vblk0.1
VFS: mounting devfs at /dev
VFS: mounting procfs at /proc
program zpool.so returned 1
BSD shrinker: event handler list found: 0xa1e6ca80
BSD shrinker found: 1
BSD shrinker: unlocked, running
[I/42 dhcp]: Waiting for IP...
[I/252 dhcp]: Server acknowledged IP for interface eth0
eth0: 192.168.122.15
[I/252 dhcp]: Configuring eth0: ip 192.168.122.15 subnet mask
255.255.255.0 gateway 192.168.122.1 MTU 1500
args
0
1.5
4.0
6.0
6.5
6.0
6.2
6.1
typ != _STT_FUNC %i
true 0 bind != _STB_GLOBAL && bind != _STB_WEAK %i
falsesym.st_shndx == _SHN_UNDEF %ifalse6.5
6.0
6.5
7
osinit
schedinit enter
schedinit 1
schedinit 2
schedinit 3
schedinit 4
schedinit 5
schedinit 6
schedinit 7
schedinit 8
alginit 1
alginit 2
alginit 3
getRandomData 1
getRandomData 3
getRandomData 4
random: blocking on read.
random: device unblocked.
getRandomData 5
getRandomData 6
getRandomData 7
alginit 4
schedinit 9
schedinit 10
schedinit 11
schedinit 12
schedinit 13
schedinit 14
schedinit 15
schedinit 16
schedinit 17
schedinit 18
schedinit 19
schedinit 21
schedinit 25
schedinit 27
schedinit exit
newproc enter
newproc exit
mstart enter
sigaltstack() stubbed
mstart enter
mstart enter
newproc enter
blub

[backtrace]
0x00202525 
0x0032a97a 
0x00388b98 
0x00387a36 
0x1147e0d2 
0x1147f15b 
0x1147c7db 
0x1147c6cc 
0x114cf232 
0x2055ff3f 



On Fri, Oct 14, 2016 at 3:57 PM, Tomasz Grabiec 
wrote:

>
>
> On Fri, Oct 14, 2016 at 3:39 PM, Benoît Canet  > wrote:
>
>>
>> Hello list,
>>
>> In the process of porting go to OSv I noticed that the Go runtime
>> initialization stall half the time waiting in a read for /dev/urandom.
>>
>> The message OSv output is "random: blocking on read.".
>>
>> It then sometime proceeed to unblock itself a couple dozen of seconds
>> later.
>>
>> Does it ring a bell ? Is it expected behavior from /dev/urandom ?
>>
>
> It looks like entropy pool was depleted. Maybe no hardware entropy sources
> were detected and we were using only slow interrupt entropy harvesting.
>
> Another option is that you are using virtio-rng and entropy was depleted
> on your host. Check with `cat /proc/sys/kernel/random/entropy_avail`
>
> Which hypervisor are you running on?
>
> Can you show your debug console output?
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.