From owner-svn-src-all@freebsd.org Sat Apr 11 22:23:37 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 560F027D5D9; Sat, 11 Apr 2020 22:23:37 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward500o.mail.yandex.net (forward500o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::610]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4908Y46wgfz4CQb; Sat, 11 Apr 2020 22:23:36 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback25o.mail.yandex.net (mxback25o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::76]) by forward500o.mail.yandex.net (Yandex) with ESMTP id D51766030D; Sun, 12 Apr 2020 01:23:32 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback25o.mail.yandex.net (mxback/Yandex) with ESMTP id a2kras6fg0-NWaKIAge; Sun, 12 Apr 2020 01:23:32 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1586643812; bh=4w9v8pCLScXumRK5Ey8m4O+bVSB4FA9YV/oSlBlmBtE=; h=Message-Id:Cc:Subject:In-Reply-To:Date:References:To:From; b=p93VXC/Ug/0tCpYGtbKOvlMSgsNp6bajKNOfmmZgA5ogEOE1nDJtbg1I8ORb0AJ1e +B3vqX6bEnxKK5EUqhftKPlkXAvC6bx3yBRdXjJ60MbkhutM/lCEGFFf16xcmn/++F QzeZvietxIFHn3MqfHoN95duct4/XEZ53pnxNkbc= Received: by myt6-887fb48a9c29.qloud-c.yandex.net with HTTP; Sun, 12 Apr 2020 01:23:32 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: "cem@freebsd.org" Cc: svn-src-all , svn-src-head , src-committers In-Reply-To: References: <202004110737.03B7b8cS067986@repo.freebsd.org> <6140881586636906@vla5-dcf36e533bf7.qloud-c.yandex.net> Subject: Re: svn commit: r359797 - in head/sys: net netinet netinet6 MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 11 Apr 2020 23:23:32 +0100 Message-Id: <6191651586642867@vla5-4a37cde0b550.qloud-c.yandex.net> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 4908Y46wgfz4CQb X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2020 22:23:37 -0000 11.04.2020, 22:28, "Conrad Meyer" : > On Sat, Apr 11, 2020 at 1:45 PM Alexander V. Chernikov > wrote: >>  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. > > Thanks! Does it need to be stable over time, or would it be > acceptable to be updated at some point? If "at some point" means "after N hours/days" than the short answer is no. In the multi-layer CLOS-like networks people usually try to reduce the amount of churn, even in presence of some failures. Changing that number results in increased randomness around the traffic flow, which doesn't bring any obvious benefit. I could potentially imagine user being able to override the number, but typically vendors don't do that. > >>  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? > > SI_SUB_LAST is better, sure. If you want to ensure you eventually get > a random number, and changing the number at runtime is acceptable, you > could have userspace induce seeding. But maybe that is unnecessarily Yep, that's a tradeoff between the ideal solution and implementation complexity. I was thinking of an approach when first rtsock connection triggers this generation, but that looks a bit ugly. If we have a good change to get somewhat decent entropy at SI_SUB_LAST, then I guess that's "good enough". > complex. Typical x86 systems using loader will have good entropy > available already at this point, outside of the installer or if there > is /boot corruption. > > (It sounds like this application would be fine with not really random > numbers, at least early in boot. We don't have a great API for that > need today, unfortunately.) Yep, for this value to be used, one need to install multipath route towards particular destination and it has to be actually used by the outbound traffic. Even if it is, nothing exceptionally bad will happen event with 0 value. > > Cheers, > Conrad