Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Apr 2020 13:02:10 -0700
From:      Conrad Meyer <cem@freebsd.org>
To:        "Alexander V. Chernikov" <melifaro@freebsd.org>
Cc:        svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org>,  src-committers <src-committers@freebsd.org>
Subject:   Re: svn commit: r359797 - in head/sys: net netinet netinet6
Message-ID:  <CAG6CVpXrVDso1i1Sq3KYVXi5%2BHyW7kwTYbq6C7otAPbCDWdgkg@mail.gmail.com>
In-Reply-To: <202004110737.03B7b8cS067986@repo.freebsd.org>
References:  <202004110737.03B7b8cS067986@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Alexander,

On Sat, Apr 11, 2020 at 12:37 AM Alexander V. Chernikov
<melifaro@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 =3D arc4random();
> -       if (in6_inithead(head, off, fibnum) =3D=3D 1) {
> -               rnh =3D (struct rib_head *)*head;
> -               rnh->rnh_multipath =3D 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
=E2=80=94 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXrVDso1i1Sq3KYVXi5%2BHyW7kwTYbq6C7otAPbCDWdgkg>