Oddity with $GET_ENTROPY and buffers larger than 16 bytes

[jonesd]

I wrote a test program to investigate $GET_ENTROPY behavior with different buffer sizes. If the buffer size if over 16 bytes and not a multiple of 16 bytes, many of the bytes it writes into the buffer are not random over repeated calls (even over different image activations).

My environment is the 9.2-1 field test upgraded to the production release (X860921OE ISO) running under VirtualBox on an i5 laptop.

SQLite wants to seed its PRNG with 44 bytes of random data, but trying to get it with a single call to SYS$GET_ENTROPY only returns 17.

[dgordon]

Any problem report should contain the hypervisor type and version, please.

What does SHOW ENTROPY tell you?

I'm looking at it now.

[jonesd]

Any problem report should contain the hypervisor type and version, please.

What does SHOW ENTROPY tell you?

The hypervisor is VirtualBox 7.0.6 r155176 (Qt5.15.2), running on Windows 11.

Code: Select all

$ show entropy
RANDOM_SOURCES:     FFFFFFFF
Enabled Sources:    000107FF
Disabled Sources:   FFFEF800
 
Sources enabled by RANDOM_SOURCES:
 
Bit  Description
---  -----------------
 0   Cached Random Data 
 1   Device Attachment 
 2   Per-CPU counters 
 3   Lock Manager 
 4   Cluster events 
 5   Tunnel sources 
 6   Ethernet Packets 
 7   Device Interrupts 
 8   Software Interrupts 
 9   File System 
10   Pool Packet Deallocation 
16   RDRAND Instruction 
17   VIRTIO Random Device (disabled)
 
System hardware supports the RDRAND instruction.
The hypervisor supports the RDRAND instruction.

[dgordon]

It's a bug. As a workaround, round your buffer size up to a multiple of 8 (max 256) and use only as much as you need. This will definitely go out in the first round of patch kits.

Using a buffer length that isn't a multiple of 8 will cost you a memcpy anyway (and that's where this bug lurks -- in the entropy code, memcpy is fine) so doing the round-up is a (small) win.

[jonesd]

It's a bug. As a workaround, round your buffer size up to a multiple of 8 (max 256) and use only as much as you need. This will definitely go out in the first round of patch kits.

Using a buffer length that isn't a multiple of 8 will cost you a memcpy anyway (and that's where this bug lurks -- in the entropy code, memcpy is fine) so doing the round-up is a (small) win.

It's multiples of 16 that work (56, a multiple of 8, doesn't). Note that this bug only appears when the buffer size is greater than 16, so you can do the first call with the highest multiple of 16 less than or equal to buffer size and the second call passing it the remainder of the buffer (guaranteed to be less than 16) if needed. Filling a 44 byte buffer would thus be sys$get_entropy(buffer,32) followed by sys$get_entropy(&buffer[32],12).

[dgordon]

I was just coming in to edit my answer to "multiples of 16" from multiples of 8. I had misremembered what the symbolic constant was in the code.

Any multiple of 16 up to 256 will return all the requested data.