From owner-svn-src-all@freebsd.org Sat Apr 11 21:28:33 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 AD59027BC9A; Sat, 11 Apr 2020 21:28:33 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4907KY3wQTz48Nw; Sat, 11 Apr 2020 21:28:33 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-oi1-f174.google.com with SMTP id j16so4391589oih.10; Sat, 11 Apr 2020 14:28:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=HWm3WWZhQsoLI1ug9TCNPIYiX4bS2XQR4bO11hFj/1Q=; b=Zh3a01EE/5bo7M6o5Y8kEM5hJGz8Wgz9NfTwDMRyVVrlGWh9VriiQA3pWpOFtB7XBA au+gyw1cnOD0XoZ8KoWc38FJGtN+5Hbwjxip9dn7VWus20FXbNDrcovukTeAkYOi7tGL cf0jUzhPajEBdORQgGQ0y1jjwu09YTXzg1CPFMTHPxJJDjLuGkSWwF43ri9+8YU+NO3t NlypWKmxTvDO43JCrCjdgQztEXO5UwCyz9fs770wBS5AAId+CaTHtXcHvYtBpAQWfzAs Q4udONdktQ7+ddTYIULVcPD8EJpDzfjx4ZBjOO7KnvHAFslzCAbyeG3AkkDvcID522ZT Yh5g== X-Gm-Message-State: AGi0PubPoLGTtw5HCstxbEsQPx3rO8JNfQQcZVT+Ry3S2Mh9FIORQ6G7 dNmXNZIpjRYMOIzVidmYKjeZ6nTS X-Google-Smtp-Source: APiQypJorn/kqRca7fka56b+vd1efeghFVXHVRJdDJtZeZywgeX6I+YArreyAnp7zxB3mnbBQvs0XA== X-Received: by 2002:a54:481a:: with SMTP id j26mr7533899oij.172.1586640512163; Sat, 11 Apr 2020 14:28:32 -0700 (PDT) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com. [209.85.210.49]) by smtp.gmail.com with ESMTPSA id q12sm3308753otn.43.2020.04.11.14.28.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Apr 2020 14:28:31 -0700 (PDT) Received: by mail-ot1-f49.google.com with SMTP id i27so2466553ota.7; Sat, 11 Apr 2020 14:28:31 -0700 (PDT) X-Received: by 2002:a9d:6d98:: with SMTP id x24mr7690273otp.157.1586640511710; Sat, 11 Apr 2020 14:28:31 -0700 (PDT) MIME-Version: 1.0 References: <202004110737.03B7b8cS067986@repo.freebsd.org> <6140881586636906@vla5-dcf36e533bf7.qloud-c.yandex.net> In-Reply-To: <6140881586636906@vla5-dcf36e533bf7.qloud-c.yandex.net> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Sat, 11 Apr 2020 14:28:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r359797 - in head/sys: net netinet netinet6 To: "Alexander V. Chernikov" Cc: svn-src-all , svn-src-head , src-committers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4907KY3wQTz48Nw X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; TAGGED_FROM(0.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 21:28:33 -0000 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 mu= ltiple paths available for the same prefix. It means to mitigate hash polar= ization in the network ( https://www.cisco.com/c/en/us/support/docs/ip/expr= ess-forwarding-cef/116376-technote-cef-00.html contains somewhat relevant d= escription). > I don't think it that knowing the number make DoSing of the particular sy= stem easier. Thanks! Does it need to be stable over time, or would it be acceptable to be updated at some point? > 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 gen= eration 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 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.) Cheers, Conrad