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

Re: xen, x86 intr code rototil alert.

[Cherry G . Mathew]

Manuel Bouyer  writes:

> On Mon, Nov 06, 2017 at 12:59:45AM +0530, Cherry G. Mathew wrote:
>> Hello,
>> 
>> As threatened earlier [1], I checked in a bunch of preparatory commits
>> for the big one - to overhaul our PV interrupt codepath and to unify it
>> with the x86/intr.c paths.
>> 
>> This would help abstract out several things, as well as make it much
>> easier for PVHVM to happen sanely.
>> 
>> I really would appreciate it if people would test Xen  -current on
>> amd64/i386 - dom0/domU and shout if anything is broken that wasn't
>> before these changes.
>
> note that there are automatic domU tests here:
> http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/
>

Very nice - bookmarked, thanks!

> Seems to be broken since the 2017-10-28 08:50 UTC run,
> maybe related to the exec changes. It may already be fixed.

Yeah - 2 Nov - I'll keep an eye on there for post 4th/5th Nov.

-- 
~cherry

Re: xen, x86 intr code rototil alert.

[Manuel Bouyer]

On Mon, Nov 06, 2017 at 12:59:45AM +0530, Cherry G. Mathew wrote:
> Hello,
> 
> As threatened earlier [1], I checked in a bunch of preparatory commits
> for the big one - to overhaul our PV interrupt codepath and to unify it
> with the x86/intr.c paths.
> 
> This would help abstract out several things, as well as make it much
> easier for PVHVM to happen sanely.
> 
> I really would appreciate it if people would test Xen  -current on
> amd64/i386 - dom0/domU and shout if anything is broken that wasn't
> before these changes.

note that there are automatic domU tests here:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/

Seems to be broken since the 2017-10-28 08:50 UTC run,
maybe related to the exec changes. It may already be fixed.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--