Zoran> But before that, after doing some tests, I found out that we
Zoran> need to keep some version of RAND_poll (the patch removes it,
Zoran> and then the system does not seem to like that; something
Zoran> about unresolved symbols and stuff ;-) ). A google search
Zoran> returns this message ID with a random device and a RAND_poll
Zoran> implementation for VxWorks:
Zoran> <adighp$ven$[EMAIL PROTECTED]> but I am not sure how
Zoran> portable or how good it is. We could also just leave a blank
Zoran> implementation and force the user to seed the PRNG themselves.
Zoran> Your call.
Arrgh! I didn't know that this was gated to usenet! My poor email
address.
That cited code was adapted (very generally) from a Solaris
"/dev/random". It requires that some other driver provide entropy.
In my system, I use a touch screen controller and a key pad to gather
this. I have heard debates over whether it is appropriate to use
network interrupt for this purpose.
The calls are,
randomFd = open(DEV_RANDOM, O_WRONLY, 0);
and then,
/* Allow random driver to note the event. */
if(randomFd > 0)
write(randomFd, "k", 1);
This was put in the hook that reads a key and a touch press. Every
time a key is read, the driver will read the clock and use a delta of
the previous time to provide some bits of entropy.
If a driver isn't properly supplied with randomly timed interrupts, it
defaults to a simple congruential random number generator. Most PRNG
will not be that much better. They will be predictable if the system
does not have a file system to store seeds. Knowing a network command
to reset the vxWorks 4.4 BSD stack (and the vxWorks client) will allow
an attacker to set the PRNG sequence. Having the user seed the PRNG
is probably not great. Perhaps the driver should be made to give an
error if there is insufficient data and the "rand_vx.c" print some
error like the other OS's.
>> I've finally started looking at your VxWorks patch. It looks
>> good, except for two things I strongly disagree with:
[snip]
>> 2. As far as I can see, splitting up the arguments to makedepend
>> with -- like you do is not necessary, and actually
>> counterproductive, at least according to the manual I have.
Zoran> I am not sure why do you think it is counterproductive, since
Zoran> without -- makedepend does not work. The issue comes up when
Zoran> there are various options within CFLAGS that start with -f,
Zoran> which is very common when compiling for VxWorks. For example,
Zoran> with these options in CFLAGS:
Zoran> -fvolatile -fno-builtin -fno-for-scope -fsigned-char
I am compiling libcrypto and libssl with,
-ansi -nostdinc -O2 -mno-sched-prolog -fno-builtin
-fno-volatile -DCPU=ARMARCH3 -Wall -Werror
I don't believe that you need "-fsigned-char" or either
"-fno-volatile" or "-fvolatile". The vxWorks programmers guide
recommends using "-fvolatile" because they don't wish to get a lot of
support calls. Most CPU's are "signed-char" except for the ARM. I
have no problem compiling without this option on the ARM (which is
-funsigned-char by default). See Rusell King's notes on this.
"http://www.arm.linux.org.uk/docs/faqs/signedchar.shtml";
Mips and IRIX have unsigned chars too. I think that OpenSSL is coded
to properly handle this. I compile with "-Wall -Werror" and I don't
get warnings about sign mismatches.
Unfortunatley my host is x86-win32. Will the vxWorks patches work for
windows hosts? This seems to be the majority of vxWorks users (at the
very least it is split 50/50).
fwiw,
Bill Pringlemeir.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
