Re: Randomization from the bootblocks
Theo de Raadt cvs.openbsd.org> writes: > >Having no interrupt (and such) entropy means less entropy. > > > >>From other hand, there are lot of speculations about some > >hardware entropy sources are suspected (proven?) bad (or > >intentionally hijacked?). > > > >So question here is, does moving random generation closer > >to hardware paves a way to more predictable numbers? > > It is clear you don't understand the code that was commited. You're right. Now I see: the code in question tries to XOR *over* hardware randomness.
Re: Randomization from the bootblocks
On 01/02/14 11:50, Alexey Suslikov wrote: Theo de Raadt cvs.openbsd.org> writes: This requires an upgrade of the bootblocks and at least /etc/rc (which saves an entropy file for future use). Some bootblocks will be able to use machine-dependent features to improve the entropy even further (for instance using random instructions or fast-running counters or such). As a result, the kernel can start using arc4random() exceedingly early on, even before interrupt entropy is collected. The randomization subsystem can hopefully become simpler due to this early entropy.. there is more work do here. I have a question. Having no interrupt (and such) entropy means less entropy. From other hand, there are lot of speculations about some hardware entropy sources are suspected (proven?) bad (or intentionally hijacked?). So question here is, does moving random generation closer to hardware paves a way to more predictable numbers? The generation itself is not going anywhere. The various entropy sources adds up, so one entropy source providing bad data should leave the random quality unaffected, at worst. /Alexander Cheers, Alexey
Re: Randomization from the bootblocks
>Theo de Raadt cvs.openbsd.org> writes: > >> This requires an upgrade of the bootblocks and at least >> /etc/rc (which saves an entropy file for future use). Some >> bootblocks will be able to use machine-dependent features >> to improve the entropy even further (for instance using >> random instructions or fast-running counters or such). >> >> As a result, the kernel can start using arc4random() >> exceedingly early on, even before interrupt entropy is >> collected. The randomization subsystem can hopefully >> become simpler due to this early entropy.. there is more >> work do here. > >I have a question. > >Having no interrupt (and such) entropy means less entropy. > >>From other hand, there are lot of speculations about some >hardware entropy sources are suspected (proven?) bad (or >intentionally hijacked?). > >So question here is, does moving random generation closer >to hardware paves a way to more predictable numbers? It is clear you don't understand the code that was commited.
Re: Randomization from the bootblocks
On Thu, Jan 02, 2014 at 12:50, Alexey Suslikov wrote: > I have a question. > > Having no interrupt (and such) entropy means less entropy. > > From other hand, there are lot of speculations about some > hardware entropy sources are suspected (proven?) bad (or > intentionally hijacked?). > > So question here is, does moving random generation closer > to hardware paves a way to more predictable numbers? The previous "random" pid algorithm for early processes was previous pid + 1. Even the backdoor in your CPU can do better than that... The operation of the random number device hasn't changed, except that its initial seed has changed to not be all zero.
Re: Randomization from the bootblocks
> At least i386, amd64, macppc, sparc64, hppa, and loongson
> are supported. Hopefully the others are not far behind.
Oh someone will ask how to verify this is working correctly. Well,
you can't really tell.
The following kernel diff will let you know that the propolice cookie
has come from data supplied early on by the bootblocks, otherwise it
has to replace it:
Index: init_main.c
===
RCS file: /cvs/src/sys/kern/init_main.c,v
retrieving revision 1.196
diff -u -p -u -r1.196 init_main.c
--- init_main.c 28 Dec 2013 20:52:48 - 1.196
+++ init_main.c 28 Dec 2013 22:55:27 -
@@ -412,11 +409,13 @@ main(void *framep)
#endif
#if !defined(NO_PROPOLICE)
+ printf("original %lx\n", __guard_local);
if (__guard_local == 0) {
volatile long newguard;
arc4random_buf((void *)&newguard, sizeof newguard);
__guard_local = newguard;
+ printf("new %lx\n", __guard_local);
}
#endif
This might help someone add support to a missing architecture; it
is a good hint anyways.
