svn commit: r359797 - in head/sys: net netinet netinet6

[Alexander V. Chernikov]

11.04.2020, 21:58, "Ian Lepore" <ian at freebsd.org>:
> On Sat, 2020-04-11 at 13:02 -0700, Conrad Meyer wrote:
>>  Hi Alexander,
>>
>>  On Sat, Apr 11, 2020 at 12:37 AM Alexander V. Chernikov
>>  <melifaro at freebsd.org> wrote:
>>  >
>>  > Author: melifaro
>>  > Date: Sat Apr 11 07:37:08 2020
>>  > New Revision: 359797
>>  > URL: https://svnweb.freebsd.org/changeset/base/359797
>>  >
>>  > Log:
>>  > Remove per-AF radix_mpath initializtion functions.
>>  >
>>  > Split their functionality by moving random seed allocation
>>  > to SYSINIT and calling (new) generic multipath function from
>>  > standard IPv4/IPv5 RIB init handlers.
>>  > ...
>>  > --- head/sys/net/radix_mpath.c Sat Apr 11 07:31:16
>>  > 2020 (r359796)
>>  > +++ head/sys/net/radix_mpath.c Sat Apr 11 07:37:08
>>  > 2020 (r359797)
>>  > @@ -290,38 +290,18 @@ rtalloc_mpath_fib(struct route *ro, uint32_t
>>  > hash, u_i
>>  > ...
>>  > +static void
>>  > +mpath_init(void)
>>  > {
>>  > - struct rib_head *rnh;
>>  >
>>  > hashjitter = arc4random();
>>  > - if (in6_inithead(head, off, fibnum) == 1) {
>>  > - rnh = (struct rib_head *)*head;
>>  > - rnh->rnh_multipath = 1;
>>  > - return 1;
>>  > - } else
>>  > - return 0;
>>  > }
>>  > +SYSINIT(mpath_init, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, mpath_init,
>>  > NULL);
>>
>>  This is pretty early in boot to be asking for random numbers. We
>>  don't have interrupts yet, for example. If the system doesn't have a
>>  saved /boot/entropy loaded (PPC, or installer, or some other embedded
>>  system perhaps), we will either deadlock boot or get not especially
>>  random numbers here (depending on availability behavior of arc4random
>>  — currently we err on the side of low quality random numbers).
>>
>>  If this number is predictable to an attacker, is it easier to DoS the
>>  system? Do we need the random number before userspace starts? (I
>>  would imagine networking does not really start chatting with remote
>>  hosts prior to userspace boot, but this is just a guess.)
>>
>>  Best,
>>  Conrad
>
> I believe the earliest use of networking during boot is for mounting
> the rootfs using nfs. So SI_SUB_ROOT_CONF-1 might be good.
Yep, that's a good one. Generally you're right.
In this particular case, this random value is only used when we have multiple paths to a particular destination. Such configuraition implies having either routing daemon up, or static route(8) configuration applied, which will happen at least after SI_SUB_KTHREAD_INIT. With all this in mind I'm thinking of moving it to the SI_SUB_LAST to increase the chance of getting good entropy. Does this sound good to you?
>
> -- Ian