Page MenuHome GnuPG

--key-gen failing on Solaris 10
Closed, InvalidPublic

Description

--key-gen fails on recent versions of Solaris 10 with not enough entropy. Emailed
with Lauren Blume who suggested opening a ticket. Details of conversation:

  • From Laurent.

Okay, I wanted to be sure, but it looks good.

I've boiled that to a change of behaviour when gpg tries to read
/dev/random.

In a -32 kernel, it does that, if I understand correctly, it does a
check on it, probably to see if there is some entropy available, the
pollsys() always returns zero, so it never tries to read it:

open("/dev/random", O_RDONLY) = 4
fstat(4, 0xFFFFFD7FFFDFCEB0) = 0
pollsys(0xFFFFFD7FFFDFCE60, 1, 0xFFFFFD7FFFDFCF20, 0x00000000) (sleeping...)
pollsys(0xFFFFFD7FFFDFCE60, 1, 0xFFFFFD7FFFDFCF20, 0x00000000) = 0
write(3, "\n N o t e n o u g h ".., 134) = 134
pollsys(0xFFFFFD7FFFDFCE60, 1, 0xFFFFFD7FFFDFCF20, 0x00000000) (sleeping...)
pollsys(0xFFFFFD7FFFDFCE60, 1, 0xFFFFFD7FFFDFCF20, 0x00000000) = 0
pollsys(0xFFFFFD7FFFDFCE60, 1, 0xFFFFFD7FFFDFCF20, 0x00000000) (sleeping...)
pollsys(0xFFFFFD7FFFDFCE60, 1, 0xFFFFFD7FFFDFCF20, 0x00000000) = 0

I checked with a cat /dev/random that there was plenty of randomness there.

On an older kernel, the same pollsys() returns 1, so it reads, and get
what it wants:

open("/dev/random", O_RDONLY) = 5
fstat(5, 0xFFFFFFFF7FFFC308) = 0
pollsys(0xFFFFFFFF7FFFC290, 1, 0xFFFFFFFF7FFFC380, 0x00000000) = 1
read(5, "\nCB f9DC7 ; l wDD : tCC".., 300) = 300

So the problem is that check failing on more recent kernels.
unfortunately, I don't have the means to investigate, lack of time and
resources to do it, no more Solaris support for me.
Can you open a case with Oracle or the GnuPG team?
I'm not sure which would be best, though the change of behaviour might
point toward a regression.

Laurent

Le 2016/02/05 16:07 +0100, Mawson, Phil (Ge Capital) a écrit:
Thank you for responding Laurent. Here is the information you requested.
Random number device statistics:
2118 bytes generated for /dev/random
0 bytes read from /dev/random cache
32555830 bytes generated for /dev/urandom

User-level providers:

/usr/lib/security/$ISA/pkcs11_kernel.so: all mechanisms are enabled.
/usr/lib/security/$ISA/pkcs11_softtoken_extra.so: all mechanisms are
enabled. random is enabled.

Kernel software providers:

des: all mechanisms are enabled.
aes256: all mechanisms are enabled.
arcfour2048: all mechanisms are enabled.
blowfish448: all mechanisms are enabled.
sha1: all mechanisms are enabled.
sha2: all mechanisms are enabled.
md5: all mechanisms are enabled.
rsa: all mechanisms are enabled.
swrand: random is enabled.

Kernel hardware providers:

Details

Version
1.4.20,REV=2016.02.05

Event Timeline

pmawson set Version to 1.4.20,REV=2016.02.05.
pmawson added a subscriber: pmawson.

Reading the report, it seems for me that there is nothing we can do as GnuPG Team;
When poll/select returns 0 for /dev/random, it is natural for GnuPG (or any
applications) to wait.
If it is Solaris 10 kernel which changed the behaviour of /dev/random, it should
be fixed or it is better (for us) to know some way to workaround this change.

Thanks for looking at it. I'll let you know if I find a workaround.