Re: Your random numbers are not that random (UtS,L)
by tye (Sage) on Jul 21, 2012 at 23:00 UTC
|
You have easy access to the full source code and you have a string that is not hard to search for. But, when you get an error message that doesn't make enough sense to you, you can also just check perldiag, which says:
(F) When trying to initialise the random seed for hashes, Perl could not get any randomness out of your system. This usually indicates Something Very Wrong.
Which means you need to go look at the source code anyway. It was very easy for me to find this:
UV
Perl_get_hash_seed(pTHX)
{
dVAR;
const char *s = PerlEnv_getenv("PERL_HASH_SEED");
UV myseed = 0;
if (s)
while (isSPACE(*s))
s++;
if (s && isDIGIT(*s))
myseed = (UV)Atoul(s);
else
#ifdef USE_HASH_SEED_EXPLICIT
if (s)
#endif
{
/* Compute a random seed */
(void)seedDrand01((Rand_seed_t)seed());
myseed = (UV)(Drand01() * (NV)UV_MAX);
#if RANDBITS < (UVSIZE * 8)
/* Since there are not enough randbits to to reach all
* the bits of a UV, the low bits might need extra
* help. Sum in another random number that will
* fill in the low bits. */
myseed +=
(UV)(Drand01() * (NV)((((UV)1) << ((UVSIZE * 8 - RANDBI
+TS))) - 1)
»);
#endif /* RANDBITS < (UVSIZE * 8) */
if (myseed == 0) { /* Superparanoia. */
myseed = (UV)(Drand01() * (NV)UV_MAX); /* One more chanc
+e. */
if (myseed == 0)
Perl_croak(aTHX_ "Your random numbers are not that r
+andom");
}
}
PL_rehash_seed_set = TRUE;
return myseed;
}
Which suggests that a quick, temporary work-around might be to put some integer into your PERL_HASH_SEED environment variable.
| [reply] [Watch: Dir/Any] [d/l] |
|
Thanks. I'll look into that on the working and non-working cards and report back with an update. I hadn't heard of perldiag before, but even if I had, it wouldn't have helped me as C (I'm assuming it's C) is a language I don't speak and the code you have shown is, I'm sorry to say, incomprehensible to me. But I can see that copying files would not have copied environment variables and that this is not only something I can do but something likely to work.
Thanks again and regards,
John Davies
Update as promised: All the environment variables I could find, whether in Linux or Perl, were the same on both cards. The Perl ones seemed to be straight copies of the Linux ones. I was looking in %ENV. Are there other places that Perl environment variables are kept?
| [reply] [Watch: Dir/Any] |
|
The C code calls Drand01() to initialise the hash seed. However, it is returning 0 for some reason. Drand01 is a frontend macro to the system random number generator -- which one, I have no clue. You could look at Perl's configure output to figure that one out.
This method is only for randomising the hash seed. It might not be critical for the installation. If you plan to make Perl user-accessible (e.g. a web service), you might run into a denial of service attack at worst. And, indeed, you can "fix" that with the aforementioned environment variable.
| [reply] [Watch: Dir/Any] |
|
|
|
|
Re: Your random numbers are not that random
by cavac (Parson) on Jul 21, 2012 at 23:22 UTC
|
It's reasonable to assume that recent perl versions do some basic checks if seeding the random number generator works. Often enough, broken random numbers are a very big security problem..
Does your system have a *working* random number generator? What happens if you run this in your bash:
for i in {1..20}; do echo $RANDOM; done
What does ls /dev/*random show?
Here's another one: Does your system have a working clock that isn't showing something like "1970-01-01"? That sounds like a strange question, but perldoc -f srand seems to imply that it normally (also) uses the time of day for initialization. A system clock that has been reset to zero (check: "If system clock less than release date" or something like that) might make it easy to guesstimate the initial seed of the RNG, since process id and memory usage should be easy to guesstimate as well, especially if the program is run as part of the startup routine of a known embedded system.
"I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] |
Re: Your random numbers are not that random
by tobyink (Canon) on Jul 22, 2012 at 06:53 UTC
|
Not an answer to your specific issue, but more generally, have you tried App::perlbrew? It makes installing multiple versions of Perl to different locations pretty easy.
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply] [Watch: Dir/Any] |
|
Well, I've tried at least one version of perlbrew, but it crashes. It insists on running tests, and there isn't the memory on the Pi for that. Besides, I'm trying to avoid the hours of compiling that seem to be necessary. If there's a site that will give me downloadable binaries for the Pi, please let me know. My fear is that such a copy would leave me facing exactly the same problems as I'm currently getting when trying to copy a working installation.
Regards,
John Davies
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
|
Re: Your random numbers are not that random
by aitap (Curate) on Jul 22, 2012 at 07:41 UTC
|
| [reply] [Watch: Dir/Any] [d/l] |
|
Debian Wheezy, also referred to, I think, as Raspbian. All cards have had the OS created by the same process. I hadn't heard of checkinstall. Thanks - I'll investigate.
Regards,
John Davies
Update: I don't think checkinstall is going to help me, although I'll bear it in mind. The problem is that there's something - a file, some hidden variable or something else - that I'm not copying and that therefore I don't know how to put into checkinstall. If I knew what to copy, I can imagine situations where it might help. At the moment, I just want to know what it is I'm failing to copy.
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Your random numbers are not that random
by Anonymous Monk on Jul 22, 2012 at 15:21 UTC
|
Do you have anything installed to feed randomness into the system? I seen a number of ArchLinux posts about installing keys onto a Pi, and needing to have haveged running in order to get enough entropy to make a key. | [reply] [Watch: Dir/Any] |
|
As you may see above in my reply to Cavac's post, there are random "devices" and I can get apparently random numbers. But I'm not actually trying to do anything with random numbers, which is why I find the response to perl -v idiosyncratic. The difference between the working card and the problem cards is that Perl was compiled on the working card and copied from there to the problem cards. Both cards had the same image copied to them using the same computer. Apart from Perl, everything works perfectly on both cards. I cannot see how the problem can be anything other than my failure to copy something from the working card to the problem cards, as the Perl creation process is the only difference. Sorry if my frustration is showing again.
Regards,
John Davies
| [reply] [Watch: Dir/Any] [d/l] |
|
But on startup, perl is doing something with hashes i presume. Having no working random number generator is a big problem with hashes. Without it, there is a big problem with Denial of Service attacks. A simple use CGI; my $q = CGI->new; or using any other kind of hashes with user-supplied content can be a problem.
So, if getting random numbers doesn't work, it is much better for perl to fail at startup than to fail silently and expose the system to all kinds of security problems.
"I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"
| [reply] [Watch: Dir/Any] [d/l] |
|
/dev/random and /dev/urandom are used to supply entropy (randomness) to the system. They both come from the same pool of randomness in the kernel. One blocks until enough randomness is obtained to provide a number. The other tries to make due with however much randomness the kernel has (and doesn't block).
Haveged (and other programs) are means to supply the kernel with randomness. By default, haveged manages a 1M buffer of randomness. Haveged does not appear to keep open a file for this buffer of randomness, so perhaps it doesn't write the buffer to disk on shutdown.
But in any event, it seems to build the pool of randomness in the kernel faster than most other things I've tried.
| [reply] [Watch: Dir/Any] |