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

[Alexander V. Chernikov]

11.04.2020, 21:02, "Conrad Meyer" <cem at freebsd.org>:
> Hi Alexander,
Hi Conrad,
>
> 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).
Got it, that's a good datapoint!
>
> 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.)
This number only affects selection of the outbound path in presence of multiple paths available for the same prefix. It means to mitigate hash polarization in the network ( https://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/116376-technote-cef-00.html contains somewhat relevant description).
I don't think it that knowing the number make DoSing of the particular system easier.

However, better quality randomness is always good.
Speaking of "when" it is needed - you're right, it is needed pretty late in the boot process, after the userland starts.
Will moving the order to SI_SUB_LAST help or I need to trigger number generation by different means?

>
> Best,
> Conrad