Re: kaslr: better rng

[Maxime Villard]

Le 14/11/2017 à 19:33, Thor Lancelot Simon a écrit :

On Tue, Nov 14, 2017 at 02:25:00PM +0100, Maxime Villard wrote:

Le 11/11/2017 ?? 22:23, Taylor R Campbell a ??crit :

Can you just use the SHA1 in libkern (and the SHA3 that will with any
luck soon be in libkern), or are there constraints on the size of the
prekern that prevent you from doing so?


No, there are no constraints. I just didn't know we could use libkern. So you
can forget about my prng.c, I'll use libkern's SHA512 until we have SHA3.


Le 12/11/2017 ?? 03:13, Thor Lancelot Simon a ??crit :

cpu_rng already has the code needed to do this -- best to use it, perhaps?


This would mean moving cpu_rng into libkern?


Maybe so.  I guess there is MD stuff in libkern already.  Only thing is,
looking at the code to remind myself what I did, it relies on our cpu_features
mechanism.  But if you look at the code, it's very, very simple, just a
few lines really to do the work -- in this very particular case perhaps you
would be justified to duplicate it.


I'll duplicate it. By the way I don't need a PRNG in the bootloader anymore,
so I'll just add one in the prekern.

Maxime

Re: kaslr: better rng

[Thor Lancelot Simon]

On Tue, Nov 14, 2017 at 02:25:00PM +0100, Maxime Villard wrote:
> Le 11/11/2017 ?? 22:23, Taylor R Campbell a ??crit :
> > Can you just use the SHA1 in libkern (and the SHA3 that will with any
> > luck soon be in libkern), or are there constraints on the size of the
> > prekern that prevent you from doing so?
> 
> No, there are no constraints. I just didn't know we could use libkern. So you
> can forget about my prng.c, I'll use libkern's SHA512 until we have SHA3.
> 
> 
> Le 12/11/2017 ?? 03:13, Thor Lancelot Simon a ??crit :
> > cpu_rng already has the code needed to do this -- best to use it, perhaps?
> 
> This would mean moving cpu_rng into libkern?

Maybe so.  I guess there is MD stuff in libkern already.  Only thing is,
looking at the code to remind myself what I did, it relies on our cpu_features
mechanism.  But if you look at the code, it's very, very simple, just a
few lines really to do the work -- in this very particular case perhaps you
would be justified to duplicate it.

Or -- it's tiny -- grab the Intel sample code examples from
https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide
which include a tiny CPU feature prober and a little bit of glue around
RDRAND and RDSEED.  You can discard almost all the glue, or even just use
the Intel code (3-clause BSD licensed) as an example of how to probe the
feature bits.

The right thing to do I would think is to is use RDSEED if you have it;
if you don't have it, or if it fails, use RDRAND.  If you don't have either,
I guess use the TSC to key your hash function.  If you don't have that,
the RTC clock... just a few inb()/outb() to read it, and it's better than
nothing.

Here is something else you can use with only a fairly small amount of
MD code -- the processor temperature sensor on most Intel CPUs made since
around 2009.  As you can see from x86/x86/coretemp.c, it's just a couple
of MSR reads - the probe may be the hard part.

-- 
  Thor Lancelot Simont...@panix.com
 "The two most common variations translate as follows:
illegitimi non carborundum = the unlawful are not silicon carbide
illegitimis non carborundum = the unlawful don't have silicon carbide."

Re: kaslr: better rng

[Maxime Villard]

Le 11/11/2017 à 22:23, Taylor R Campbell a écrit :

Can you just use the SHA1 in libkern (and the SHA3 that will with any
luck soon be in libkern), or are there constraints on the size of the
prekern that prevent you from doing so?


No, there are no constraints. I just didn't know we could use libkern. So you
can forget about my prng.c, I'll use libkern's SHA512 until we have SHA3.


Le 12/11/2017 à 03:13, Thor Lancelot Simon a écrit :

cpu_rng already has the code needed to do this -- best to use it, perhaps?


This would mean moving cpu_rng into libkern?

Re: kaslr: better rng

[Thor Lancelot Simon]

On Sat, Nov 11, 2017 at 09:23:39PM +, Taylor R Campbell wrote:
> 
> Speaking of which, you should read 256 bits out of rdseed, not 64, and
> fall back to rdrand if rdseed is not available.

cpu_rng already has the code needed to do this -- best to use it, perhaps?

Thor

Re: kaslr: better rng

[Taylor R Campbell]

> Date: Sat, 11 Nov 2017 21:48:54 +0100
> From: Maxime Villard 
> 
> The hash of y against rdtsc and rdseed is the new secret, not just y. It's
> not a recurrent Yn+1 = H(Yn) construction from a single Y0 seed - in which
> case one leak in the chain would indeed compromise the randomness of the
> following generations. It's rather Yn+1 = H(Yn, rdtsc, rdseed), where even
> if Yn is entirely revealed, you still can't predict Yn+1 reliably.
> 
> But I understand that re-using potentially revealed information in
> the hash weakens the prng in probably non-negligible ways, and that
> splitting the output as you said is better.

A little more to the point, the kernel's cryptography should be secure
if _either_

(a) the original seed on disk is unpredictable, _or_
(b) the seed we get out of rdseed is unpredictable.

I don't expect more than a few bits of the tsc to be unpredictable,
and not every machine supports rdseed.  If we don't assume they're
unpredictable, then it reduces to Yn+1 = H(Yn) for some predictable H.

Speaking of which, you should read 256 bits out of rdseed, not 64, and
fall back to rdrand if rdseed is not available.

> > Rather, we should carve up the output of SHAKE256 into a new 32-byte secret
> > and an n-byte buffer of outputs for some convenient n:
> > 
> > nseed(32) || buffer(480) = SHAKE256(oseed(32) || whatever else)
> 
> The output size we use is 32 bytes, not 512. So I guess we should increase it
> to 64, keep the lower half secret (and pass it to the hash function), and use
> the upper half as a random (and potentially revealed) buffer?

Whatever's convenient.  It doesn't really matter for security.

> (Side note regarding "revealed": if 32byte-worth of
> randomly-generated kernel VAs were to be revealed, we would be
> having a much bigger problem in the first place.)

Yes, but it's easier to engineer this by using a generically secure
PRNG; then I don't even have to think about quantifying the impact of
downstream leaks.

> I would favor certified algorithms, not that my opinion matters lot in this
> regard.

I care about security, understandability, and maintainability, not
about certification, but as I understand it the reason we use
AES128-CTR-DRBG for /dev/random is to make certification easier.  tls@
can probably comment on this.

> > Also, where do you update the seed that is then passed to rnd_seed to
> > initialize the real kernel entropy pool?
> 
> I don't, and that's a problem. To update the seed we need to
> recompute its SHA1 signature, and I'm not implementing SHA1 in the
> prekern (yet?). Either we extend entropy-file to contain three
> separate seeds (bootloader / prekern / kernel), or we choose to use
> SHA3 by default in the kernel and have the prekern update the seed
> and recompute its signature dynamically.

Blahh!  I don't even know why we have the SHA1 hash there.

Can you just use the SHA1 in libkern (and the SHA3 that will with any
luck soon be in libkern), or are there constraints on the size of the
prekern that prevent you from doing so?

Re: kaslr: better rng

[Maxime Villard]

Le 11/11/2017 à 20:14, Taylor R Campbell a écrit :

If we _both_ reveal y = H(x) for some initial secret x, and then use y
as the new secret, we've just revealed the new secret. 


The hash of y against rdtsc and rdseed is the new secret, not just y. It's
not a recurrent Yn+1 = H(Yn) construction from a single Y0 seed - in which
case one leak in the chain would indeed compromise the randomness of the
following generations. It's rather Yn+1 = H(Yn, rdtsc, rdseed), where even
if Yn is entirely revealed, you still can't predict Yn+1 reliably.

But I understand that re-using potentially revealed information in the hash
weakens the prng in probably non-negligible ways, and that splitting the output
as you said is better.


Rather, we should carve up the output of SHAKE256 into a new 32-byte secret
and an n-byte buffer of outputs for some convenient n:

nseed(32) || buffer(480) = SHAKE256(oseed(32) || whatever else)


The output size we use is 32 bytes, not 512. So I guess we should increase it
to 64, keep the lower half secret (and pass it to the hash function), and use
the upper half as a random (and potentially revealed) buffer?

(Side note regarding "revealed": if 32byte-worth of randomly-generated kernel
VAs were to be revealed, we would be having a much bigger problem in the first
place.)


See  for further
discussion of this structure (and criticism of the obscenely
complicated NIST DRBGs in SP800-90A).

It may be simpler to use a Keccak duplex like the draft entropy pool
I've been sitting on for a while, which has some theoretically nicer
properties[1] though hasn't yet appeared in a NIST standard the way
SHAKE256 has.  Input from someone who is likely to care about
certification more than I do would be appreciated here.


I would favor certified algorithms, not that my opinion matters lot in this
regard.


Also, where do you update the seed that is then passed to rnd_seed to
initialize the real kernel entropy pool?


I don't, and that's a problem. To update the seed we need to recompute its
SHA1 signature, and I'm not implementing SHA1 in the prekern (yet?). Either
we extend entropy-file to contain three separate seeds (bootloader / prekern /
kernel), or we choose to use SHA3 by default in the kernel and have the
prekern update the seed and recompute its signature dynamically.


Finally, some minor nits:

- Don't call it `rndpool', because that has a specific meaning in
   NetBSD already, which is something else.  Just `struct prng' is
   fine, if confined to that file.


alright


- Define functions with foo(void), not foo(), to get prototype
   checking from the C compiler.

- Newline before function name in definitions; see share/misc/style
   for more details.

- No need for casts between void * and other types.

- Use unsigned, not u_int; u_int, u_intN_t, , are vestiges of older
   days.

- Avoid externs in .c files.  Include the right header file for the
   declaration of bootinfo.


These are common in the prekern and not particularly related to the prng, so
they will be addressed later. Also need to get rid of redef.h etc.

Maxime

Re: kaslr: better rng

[Taylor R Campbell]

> Date: Sat, 11 Nov 2017 15:48:12 +0100
> From: Maxime Villard 
> 
> It is based on the SHAKE256 hash function, which can produce a variable
> sized output. We use an area of 32 bytes, and regenerate it as many times
> as needed.
> 
> The first time, it is generated with:
> 
>   area = SHAKE256(entropy-file, rdseed, rdtsc)
> 
> When all of the bytes in the area have been consumed, it is regenerated
> this way:
> 
>   area = SHAKE256(area, rdseed, rdtsc)

If we _both_ reveal y = H(x) for some initial secret x, and then use y
as the new secret, we've just revealed the new secret.  Rather, we
should carve up the output of SHAKE256 into a new 32-byte secret and
an n-byte buffer of outputs for some convenient n:

nseed(32) || buffer(480) = SHAKE256(oseed(32) || whatever else)

See  for further
discussion of this structure (and criticism of the obscenely
complicated NIST DRBGs in SP800-90A).

It may be simpler to use a Keccak duplex like the draft entropy pool
I've been sitting on for a while, which has some theoretically nicer
properties[1] though hasn't yet appeared in a NIST standard the way
SHAKE256 has.  Input from someone who is likely to care about
certification more than I do would be appreciated here.

Also, where do you update the seed that is then passed to rnd_seed to
initialize the real kernel entropy pool?

Finally, some minor nits:

- Don't call it `rndpool', because that has a specific meaning in
  NetBSD already, which is something else.  Just `struct prng' is
  fine, if confined to that file.

- Define functions with foo(void), not foo(), to get prototype
  checking from the C compiler.

- Newline before function name in definitions; see share/misc/style
  for more details.

- No need for casts between void * and other types.

- Use unsigned, not u_int; u_int, u_intN_t, , are vestiges of older
  days.

- Avoid externs in .c files.  Include the right header file for the
  declaration of bootinfo.


[1] https://keccak.team/files/SpongePRNG.pdf

Re: kaslr: better rng

[Maxime Villard]

Following a conversation with Taylor, I ended up with the following
implementation for the prekern [1] [2]. It uses a set of seeds that are
hashed together in rounds, and it doesn't use an additional file.

It is based on the SHAKE256 hash function, which can produce a variable
sized output. We use an area of 32 bytes, and regenerate it as many times
as needed.

The first time, it is generated with:

area = SHAKE256(entropy-file, rdseed, rdtsc)

When all of the bytes in the area have been consumed, it is regenerated
this way:

area = SHAKE256(area, rdseed, rdtsc)

The SHAKE/Keccak code is from Taylor, I just added prng_* wrappers.

rdseed and rdtsc each give a 8byte seed, and entropy-file gives a 512byte
one. We don't checksum the latter, because we would need SHA1, which I am
not implementing here.

Feel free to tell me if there's something obviously wrong in all of this;
I won't hide that PRNGs are not things I work on every day.

[1] http://m00nbsd.net/garbage/prekern/prng.c
[2] http://m00nbsd.net/garbage/prekern/prng.diff

re: kaslr: better rng

[matthew green]

> Ah alright. But in my mail (that you were answering to) I did understand that
> the entropy file comes from the previous run; what I was saying was, I would
> prefer the file in question to contain random data right away and not just a
> seed. In such a way that whoever wants to get random uints at boot time can
> read the file and obtain some, with no generation algorithm whatsoever.

this idea is seriously flawed.  there's no guarantee that the
entropy file will be updated every boot, so there's a very
high chance of reusing the same "random" data.  it should
always go through some thing else before use.


.mrg.

Re: kaslr: better rng

[Taylor R Campbell]

> Date: Wed, 8 Nov 2017 18:23:11 +0100
> From: Maxime Villard 
> 
> Le 08/11/2017 à 18:17, Maxime Villard a écrit :
> > Le 08/11/2017 à 17:37, Taylor R Campbell a écrit :
> >> What's the advantage of (a) changing the on-disk file hierarchy and
> >> generating the data on shutdown, versus (b) leaving the on-disk file
> >> hierarchy unchanged and generating the data on boot?
> > 
> > The randomness of (b) is stronger than that of (a). But perhaps in a scale
> > that is so insignificant that we actually don't care (?).
> 
> obviously I meant the contrary: the randmoness of (a) is stronger than that
> of (b), sorry about that

There is no meaningful difference between storing a seed on disk and
storing the output of expanding that seed into a pad on disk.  Either
way the seed is derived from SHA1(entropypool) at the moment.

We can argue about how to expand the seed (AES128-CTR-DRBG, SHAKE256,
ChaCha, whatever) but the point remains the same.

(Generally I would recommend SHAKE256 for ~everything here, since
nobody will ever get fired for choosing NIST standards, and it
obviously has an higher security margin than AES128, and I have a very
small easy-to-audit implementation handy already that almost made it
into src a couple years ago anyway but for possible incompatibility
with OpenSSL's SHA-3 API in libc.)

Re: kaslr: better rng

[Maxime Villard]

Le 08/11/2017 à 18:17, Maxime Villard a écrit :

Le 08/11/2017 à 17:37, Taylor R Campbell a écrit :

Date: Wed, 8 Nov 2017 17:08:42 +0100
From: Maxime Villard 

Ah alright. But in my mail (that you were answering to) I did understand that
the entropy file comes from the previous run; what I was saying was, I would
prefer the file in question to contain random data right away and not just a
seed. In such a way that whoever wants to get random uints at boot time can
read the file and obtain some, with no generation algorithm whatsoever.


What's the advantage of (a) changing the on-disk file hierarchy and
generating the data on shutdown, versus (b) leaving the on-disk file
hierarchy unchanged and generating the data on boot?


The randomness of (b) is stronger than that of (a). But perhaps in a scale
that is so insignificant that we actually don't care (?).


obviously I meant the contrary: the randmoness of (a) is stronger than that
of (b), sorry about that

Re: kaslr: better rng

[Maxime Villard]

Le 08/11/2017 à 17:37, Taylor R Campbell a écrit :

Date: Wed, 8 Nov 2017 17:08:42 +0100
From: Maxime Villard 

Ah alright. But in my mail (that you were answering to) I did understand that
the entropy file comes from the previous run; what I was saying was, I would
prefer the file in question to contain random data right away and not just a
seed. In such a way that whoever wants to get random uints at boot time can
read the file and obtain some, with no generation algorithm whatsoever.


What's the advantage of (a) changing the on-disk file hierarchy and
generating the data on shutdown, versus (b) leaving the on-disk file
hierarchy unchanged and generating the data on boot?


The randomness of (b) is stronger than that of (a). But perhaps in a scale
that is so insignificant that we actually don't care (?).

Re: kaslr: better rng

[Taylor R Campbell]

> Date: Wed, 8 Nov 2017 17:08:42 +0100
> From: Maxime Villard 
> 
> Ah alright. But in my mail (that you were answering to) I did understand that
> the entropy file comes from the previous run; what I was saying was, I would
> prefer the file in question to contain random data right away and not just a
> seed. In such a way that whoever wants to get random uints at boot time can
> read the file and obtain some, with no generation algorithm whatsoever.

What's the advantage of (a) changing the on-disk file hierarchy and 
generating the data on shutdown, versus (b) leaving the on-disk file
hierarchy unchanged and generating the data on boot?

Re: kaslr: better rng

[Maxime Villard]

Le 07/11/2017 à 17:21, Taylor R Campbell a écrit :

Date: Tue, 7 Nov 2017 09:16:25 +0100
From: Maxime Villard 

Le 06/11/2017 à 19:47, Taylor R Campbell a écrit :

The entropy file is supposed to be rewritten each time it's read, and
on shutdown, or something like that.


Yes, I know that. But what is the point you're trying to make?


The original quotation I was replying to was this:


Well, we could indeed extend /var/db/entropy-file. However, I would really
prefer the random area to be generated from a previous run of the system, and
not from the bootloader taking a seed in the file. Unless there is a
combination of both?


I was trying to point out that the entropy file _does_ come from a
previous run of the system.


Ah alright. But in my mail (that you were answering to) I did understand that
the entropy file comes from the previous run; what I was saying was, I would
prefer the file in question to contain random data right away and not just a
seed. In such a way that whoever wants to get random uints at boot time can
read the file and obtain some, with no generation algorithm whatsoever.


Le 06/11/2017 à 22:31, paul.kon...@dell.com a écrit :

If you think you need this file, I would argue there should be two: the
current entropy file for the kernel to use, and a separate one generated
from a different chunk of random bit stream, exclusively for the use next
time by the bootloader.


Well yes, my initial plan was two different files.


What's the security goal you hope to achieve by having two different
files that cannot be achieved by using one and deriving two subkeys
from it?


There is no particular security goal behind this. Since I wanted the file not
to be a seed, it made sense to use two different files (one seed, one
random...).

Maxime

Re: kaslr: better rng

[Paul.Koning]

> On Nov 7, 2017, at 11:21 AM, Taylor R Campbell 
>  wrote:
> 
>> Date: Tue, 7 Nov 2017 09:16:25 +0100
>> From: Maxime Villard 
>> ...
>> Well yes, my initial plan was two different files.
> 
> What's the security goal you hope to achieve by having two different
> files that cannot be achieved by using one and deriving two subkeys
> from it?

If you use two parts of a single file that's equivalent to using two files.

If two RNGs use the same data from the file as the starting point, then you 
have to argue security from the strengths of the two derivations.  Presumably 
they use additional entropy to make that work. If so, is the additional entropy 
enough on its own?  If yes, then you don't need the stored file in the first 
place.

paul

Re: kaslr: better rng

[Taylor R Campbell]

> Date: Tue, 7 Nov 2017 09:16:25 +0100
> From: Maxime Villard 
> 
> Le 06/11/2017 à 19:47, Taylor R Campbell a écrit :
> > The entropy file is supposed to be rewritten each time it's read, and
> > on shutdown, or something like that.
> 
> Yes, I know that. But what is the point you're trying to make?

The original quotation I was replying to was this:

> > > Well, we could indeed extend /var/db/entropy-file. However, I would really
> > > prefer the random area to be generated from a previous run of the system, 
> > > and
> > > not from the bootloader taking a seed in the file. Unless there is a
> > > combination of both?

I was trying to point out that the entropy file _does_ come from a
previous run of the system.

> Le 06/11/2017 à 21:57, matthew green a écrit :
> > it would be nice if the lack of this file wasn't a major problem
> > and that, eg, if rdrand was available it would be used as a seed
> > instead/additionally
> 
> Yes, that would be nice. A combination of rdtsc and rdrand (given that the
> latter may not be supported by the cpu).

Easy to hash together the seed, cpu_counter, and cpu_rng.

> Le 06/11/2017 à 22:31, paul.kon...@dell.com a écrit :
> > If you think you need this file, I would argue there should be two: the
> > current entropy file for the kernel to use, and a separate one generated
> > from a different chunk of random bit stream, exclusively for the use next
> > time by the bootloader.
> 
> Well yes, my initial plan was two different files.

What's the security goal you hope to achieve by having two different
files that cannot be achieved by using one and deriving two subkeys
from it?

Re: kaslr: better rng

[Maxime Villard]

Answering to each of your mails at once:


Le 06/11/2017 à 19:47, Taylor R Campbell a écrit :

The entropy file is supposed to be rewritten each time it's read, and
on shutdown, or something like that.


Yes, I know that. But what is the point you're trying to make?


Le 06/11/2017 à 21:57, matthew green a écrit :

it would be nice if the lack of this file wasn't a major problem
and that, eg, if rdrand was available it would be used as a seed
instead/additionally


Yes, that would be nice. A combination of rdtsc and rdrand (given that the
latter may not be supported by the cpu).


the two cases i see this regularly are pxe booted systems and in
the installer, both a fairly important cases so i think supporting
them as well would be worthwhile.


Perhaps, but I guess you know that we don't support kaslr over pxe, and
the interest is rather limited.


Le 06/11/2017 à 22:31, paul.kon...@dell.com a écrit :

If you think you need this file, I would argue there should be two: the
current entropy file for the kernel to use, and a separate one generated
from a different chunk of random bit stream, exclusively for the use next
time by the bootloader.


Well yes, my initial plan was two different files.


Le 07/11/2017 à 03:50, Thor Lancelot Simon a écrit :

On Mon, Nov 06, 2017 at 06:51:33PM +0100, Maxime Villard wrote:


What is the reason for using only part of the file, in any application?


I meant to say that the components don't take random values from the same
area in the file, for them not to use the same random numbers twice.


That doesn't make sense to me.  Do you believe all modern keyed hash
functions are broken?


Re-read my initial mail carefully. My plan was to have the random area
generated in the previous run, and have the bootloader/prekern/kernel take it
as-is with little to no modification/hash to it. In such a case, you had better
make sure you don't use the same areas from the file twice.

Re: kaslr: better rng

[Paul.Koning]

> On Nov 6, 2017, at 12:51 PM, Maxime Villard  wrote:
> 
> Le 06/11/2017 à 18:28, Thor Lancelot Simon a écrit :
>> On Mon, Nov 06, 2017 at 07:30:35AM +0100, Maxime Villard wrote:
>>> I'm in a point where I need to have a better rng before continuing - and an
>>> rng that can be used in the bootloader, in the prekern and in the kernel
>>> (early).
>>> 
>>> I would like to use a system similar to the /var/db/entropy-file 
>>> implementation.
>>> That is to say, when running the system generates /var/db/random-file, which
>>> would contain at least 256bytes of random data. When booting the bootloader
>>> reads this file, can use some of its bytes to get random values. It then 
>>> gives
>>> the file to the prekern which will use some other parts of it. The prekern
>>> finally gives the file to the kernel which can use the rest.
>> What is the reason for using only part of the file, in any application?
> 
> I meant to say that the components don't take random values from the same
> area in the file, for them not to use the same random numbers twice.

Yes, that's critical if the other sources of entropy aren't sufficient by 
themselves.  Then again, if they are, there is no reason to bother with this 
file in the first place.

If you think you need this file, I would argue there should be two: the current 
entropy file for the kernel to use, and a separate one generated from a 
different chunk of random bit stream, exclusively for the use next time by the 
bootloader.

paul

Re: kaslr: better rng

[Thor Lancelot Simon]

On Mon, Nov 06, 2017 at 06:51:33PM +0100, Maxime Villard wrote:
> > 
> > What is the reason for using only part of the file, in any application?
> 
> I meant to say that the components don't take random values from the same
> area in the file, for them not to use the same random numbers twice.

That doesn't make sense to me.  Do you believe all modern keyed hash
functions are broken?

If not, why not use HMAC with a suitable hash (SHA512 is probably right
for now) and two different fixed keys, over the entire boot time seed
entropy, to derive two different seeds for the two RNGs?

-- 
  Thor Lancelot Simont...@panix.com
 "The two most common variations translate as follows:
illegitimi non carborundum = the unlawful are not silicon carbide
illegitimis non carborundum = the unlawful don't have silicon carbide."

Re: kaslr: better rng

[Maxime Villard]

Le 06/11/2017 à 18:28, Thor Lancelot Simon a écrit :

On Mon, Nov 06, 2017 at 07:30:35AM +0100, Maxime Villard wrote:

I'm in a point where I need to have a better rng before continuing - and an
rng that can be used in the bootloader, in the prekern and in the kernel
(early).

I would like to use a system similar to the /var/db/entropy-file implementation.
That is to say, when running the system generates /var/db/random-file, which
would contain at least 256bytes of random data. When booting the bootloader
reads this file, can use some of its bytes to get random values. It then gives
the file to the prekern which will use some other parts of it. The prekern
finally gives the file to the kernel which can use the rest.


What is the reason for using only part of the file, in any application?


I meant to say that the components don't take random values from the same
area in the file, for them not to use the same random numbers twice.

For example, if the bootloader consumes the first four uint64_t of the file,
the prekern will virtually do an "lseek(4*sizeof(uint64_t))" and use the rest
of the file as a random pool. Same for the kernel, which will lseek over the
area consumed by the prekern.

Re: kaslr: better rng

[Taylor R Campbell]

> Date: Tue, 07 Nov 2017 07:57:58 +1100
> from: matthew green 
> 
> > Well, we could indeed extend /var/db/entropy-file. However, I would really
> > prefer the random area to be generated from a previous run of the system, 
> > and
> > not from the bootloader taking a seed in the file. Unless there is a
> > combination of both?
> 
> it would be nice if the lack of this file wasn't a major problem
> and that, eg, if rdrand was available it would be used as a seed
> instead/additionally
> 
> the two cases i see this regularly are pxe booted systems and in
> the installer, both a fairly important cases so i think supporting
> them as well would be worthwhile.

Yes -- we should hash together the file and cpu_rng.

re: kaslr: better rng

[matthew green]

> Well, we could indeed extend /var/db/entropy-file. However, I would really
> prefer the random area to be generated from a previous run of the system, and
> not from the bootloader taking a seed in the file. Unless there is a
> combination of both?

it would be nice if the lack of this file wasn't a major problem
and that, eg, if rdrand was available it would be used as a seed
instead/additionally

the two cases i see this regularly are pxe booted systems and in
the installer, both a fairly important cases so i think supporting
them as well would be worthwhile.


.mrg.

Re: kaslr: better rng

[Taylor R Campbell]

> Date: Mon, 6 Nov 2017 19:04:44 +0100
> From: Maxime Villard 
> 
> Well, we could indeed extend /var/db/entropy-file. However, I would really
> prefer the random area to be generated from a previous run of the system, and
> not from the bootloader taking a seed in the file. Unless there is a
> combination of both?

The entropy file is supposed to be rewritten each time it's read, and
on shutdown, or something like that.

> Note that such a PRNG would also have to be implemented in the prekern and
> in the kernel, and we would need three independent seeds.

keccak.o appears to be 3000 bytes long, and can be quickly adapted to
squeeze three seeds out after absorbing one with the magic of modern
cryptography.

Re: kaslr: better rng

[Maxime Villard]

Le 06/11/2017 à 18:35, Taylor R Campbell a écrit :

Date: Mon, 6 Nov 2017 07:30:35 +0100
From: Maxime Villard 

I would like to use a system similar to the /var/db/entropy-file
implementation.  That is to say, when running the system generates
/var/db/random-file, which would contain at least 256bytes of random
data. When booting the bootloader reads this file, can use some of
its bytes to get random values. It then gives the file to the
prekern which will use some other parts of it. The prekern finally
gives the file to the kernel which can use the rest.


Seems to me we should just use one file, and the bootloader should use
it as a seed for a PRNG from which it draws

(a) kaslr bits, and
(b) a seed for the entropy pool (which is currently just /var/db/entropy)

The bootloader already reads a file.  Teaching it to have a small
cryptographic PRNG shouldn't be too hard.  I'm still sitting on a
draft Keccak-based entropy pool, whose Keccak implementation
(https://mumble.net/~campbell/hg/sha3/keccak.c) likely fits in the
constraints of a bootloader.


Well, we could indeed extend /var/db/entropy-file. However, I would really
prefer the random area to be generated from a previous run of the system, and
not from the bootloader taking a seed in the file. Unless there is a
combination of both?

Note that such a PRNG would also have to be implemented in the prekern and
in the kernel, and we would need three independent seeds.

Re: kaslr: better rng

[Taylor R Campbell]

> Date: Mon, 6 Nov 2017 07:30:35 +0100
> From: Maxime Villard 
> 
> I would like to use a system similar to the /var/db/entropy-file
> implementation.  That is to say, when running the system generates
> /var/db/random-file, which would contain at least 256bytes of random
> data. When booting the bootloader reads this file, can use some of
> its bytes to get random values. It then gives the file to the
> prekern which will use some other parts of it. The prekern finally
> gives the file to the kernel which can use the rest.

Seems to me we should just use one file, and the bootloader should use
it as a seed for a PRNG from which it draws

(a) kaslr bits, and
(b) a seed for the entropy pool (which is currently just /var/db/entropy)

The bootloader already reads a file.  Teaching it to have a small
cryptographic PRNG shouldn't be too hard.  I'm still sitting on a
draft Keccak-based entropy pool, whose Keccak implementation
(https://mumble.net/~campbell/hg/sha3/keccak.c) likely fits in the
constraints of a bootloader.

Re: kaslr: better rng

[Thor Lancelot Simon]

On Mon, Nov 06, 2017 at 07:30:35AM +0100, Maxime Villard wrote:
> I'm in a point where I need to have a better rng before continuing - and an
> rng that can be used in the bootloader, in the prekern and in the kernel
> (early).
> 
> I would like to use a system similar to the /var/db/entropy-file 
> implementation.
> That is to say, when running the system generates /var/db/random-file, which
> would contain at least 256bytes of random data. When booting the bootloader
> reads this file, can use some of its bytes to get random values. It then gives
> the file to the prekern which will use some other parts of it. The prekern
> finally gives the file to the kernel which can use the rest.

What is the reason for using only part of the file, in any application?

Thor