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: locking against myself panic (cprng_strongreseed, filt_rndread)

[Taylor R Campbell]

> Date: Wed, 8 Nov 2017 11:22:26 +0100
> From: Edgar Fuß 
> 
> > Not surprising: cprng locking was completely hosed in netbsd-6 until
> > it got rewritten for netbsd-7.
> So I can expect all of my servers to panic at any time?
> Can I mitigate the probability of the panic?

If you can guarantee either

(a) you have a hardware RNG, or
(b) the system is updating and using the /var/db/entropy file,

then you can safely replace /dev/random by a symlink to /dev/urandom,
and that should avoid the panic for certain use patterns.

Specifically, processes that first try to read from /dev/random, and
then wait with select/poll/kqueue only if it returns EAGAIN, will
avoid triggering that code path by reading exclusively from (what is
actually) /dev/urandom, which never returns EAGAIN.

Processes that start by select/poll/kqueue, however, may still trigger
the bad code path.  I threw together a patch, attached, that _might_
fix this particular code path, but (a) I don't have time to test or
even compile-test it at the moment, and (b) there are lots of other
things wrong with the netbsd-6 cprng stuff, so don't get too excited.

If you'd like to test it, we can see about applying it as a `pullup'
(not that it has any connection to the changes in netbsd-7 that were a
near-total rewrite).
diff --git a/sys/dev/rndpseudo.c b/sys/dev/rndpseudo.c
index 5501263020d5..68eeaa700d3b 100644
--- a/sys/dev/rndpseudo.c
+++ b/sys/dev/rndpseudo.c
@@ -673,13 +673,13 @@ rnd_poll(struct file *fp, int events)
}   
}
 
+   mutex_enter(>cprng->mtx);
if (cprng_strong_ready(ctx->cprng)) {
revents |= events & (POLLIN | POLLRDNORM);
} else {
-   mutex_enter(>cprng->mtx);
selrecord(curlwp, >cprng->selq);
-   mutex_exit(>cprng->mtx);
}
+   mutex_exit(>cprng->mtx);
 
return (revents);
 }
@@ -731,12 +731,24 @@ static int
 filt_rndread(struct knote *kn, long hint)
 {
cprng_strong_t *c = kn->kn_hook;
+   int ret;
 
+   if (hint & NOTE_SUBMIT)
+   KASSERT(mutex_owned(>mtx));
+   else
+   mutex_enter(>mtx);
if (cprng_strong_ready(c)) {
kn->kn_data = RND_TEMP_BUFFER_SIZE;
-   return 1;
+   ret = 1;
+   } else {
+   ret = 0;
}
-   return 0;
+   if (hint & NOTE_SUBMIT)
+   KASSERT(mutex_owned(>mtx));
+   else
+   mutex_exit(>mtx);
+
+   return ret;
 }
 
 static const struct filterops rnd_seltrue_filtops =
diff --git a/sys/kern/subr_cprng.c b/sys/kern/subr_cprng.c
index 168a83066844..cdb382b84c81 100644
--- a/sys/kern/subr_cprng.c
+++ b/sys/kern/subr_cprng.c
@@ -95,7 +95,7 @@ cprng_strong_doreseed(cprng_strong_t *const c)
if (c->flags & CPRNG_USE_CV) {
cv_broadcast(>cv);
}
-   selnotify(>selq, 0, 0);
+   selnotify(>selq, 0, NOTE_SUBMIT);
 }
 
 static void
@@ -397,7 +397,7 @@ cprng_strong_setflags(cprng_strong_t *const c, int flags)
if (c->flags & CPRNG_USE_CV) {
cv_broadcast(>cv);
}
-   selnotify(>selq, 0, 0);
+   selnotify(>selq, 0, NOTE_SUBMIT);
}
}
c->flags = flags;
diff --git a/sys/sys/cprng.h b/sys/sys/cprng.h
index 984a06fb1b11..278ca3ab2885 100644
--- a/sys/sys/cprng.h
+++ b/sys/sys/cprng.h
@@ -121,12 +121,11 @@ static inline int
 cprng_strong_ready(cprng_strong_t *c)
 {
int ret = 0;
-   
-   mutex_enter(>mtx);
+
+   KASSERT(mutex_owned(>mtx));
if (c->drbg.reseed_counter < NIST_CTR_DRBG_RESEED_INTERVAL) {
ret = 1;
}
-   mutex_exit(>mtx);
return ret;
 }
 

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: mount_apfs?

[Paul.Koning]

> On Nov 8, 2017, at 5:07 AM, Edgar Fuß  wrote:
> 
>> here's a description of the APFS (Apple File System) format:
> So they didn't open-source the code?

Apparently not.  But an entry in "Hacker news" (on ycombinator) says:

An open source implementation is not available at this time. 
Apple plans to document and publish the APFS volume format when 
Apple File System is released in 2017.

No idea if that statement is accurate or not, but FWIW...

paul

Re: namei and path canonicalization

[Christos Zoulas]

On Nov 8,  6:54am, dholland-t...@netbsd.org (David Holland) wrote:
-- Subject: Re: namei and path canonicalization

| We don't, at least as of your changes this afternoon which always set
| it... I'm wondering if we should though. Any setugid program that uses
| that value is presumptively doing something dangerous, and it's not
| clear that there's anything non-dangerous that *can* be done with it.

It was set in the majority of the cases as programs ran from the
popular shells have been executed using an absolute path.

christos

Re: namei and path canonicalization

[Edgar Fuß]

> remembering the directory vnode the program was exec'd from 
> and providing a way to open it as a file handle.
Plus some extra measures so you can't escape to there after a chroot(), no?

Re: locking against myself panic (cprng_strongreseed, filt_rndread)

[Edgar Fuß]

> Not surprising: cprng locking was completely hosed in netbsd-6 until
> it got rewritten for netbsd-7.
So I can expect all of my servers to panic at any time?
Can I mitigate the probability of the panic?

Re: mount_apfs?

[Edgar Fuß]

> here's a description of the APFS (Apple File System) format:
So they didn't open-source the code?

mount_apfs?

[Thomas Klausner]

In case someone is looking for a challenge, here's a description of
the APFS (Apple File System) format:

https://blog.cugu.eu/post/apfs/

Cheers,
 Thomas