Date: Sat, 11 Apr 2020 21:45:41 +0100 From: Alexander V. Chernikov <melifaro@freebsd.org> To: "cem@freebsd.org" <cem@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: <6140881586636906@vla5-dcf36e533bf7.qloud-c.yandex.net> In-Reply-To: <CAG6CVpXrVDso1i1Sq3KYVXi5%2BHyW7kwTYbq6C7otAPbCDWdgkg@mail.gmail.com> References: <202004110737.03B7b8cS067986@repo.freebsd.org> <CAG6CVpXrVDso1i1Sq3KYVXi5%2BHyW7kwTYbq6C7otAPbCDWdgkg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
11.04.2020, 21:02, "Conrad Meyer" <cem@freebsd.org>: > Hi Alexander, Hi Conrad, > > 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 = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6140881586636906>