From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=UBcwycIa; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 64A0F5A0262 for ; Thu, 16 Jul 2026 09:22:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784186569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fOPNiWWV4uOpdc8om2Cjbh3iGeqD9fn+Fr3qU77+7s0=; b=UBcwycIa8u9R1uYk62/rog6A8d9vdFa4ZMFOHluFeX/N/Vo+uzG9cqF7SI2hDG1ogiN46n xkOss4o+cXVetfW9H4NBjKvzUa8bNkeAZwbYR6JnDGXCh0tpdg/acX3fYKYAL73xJ1MH++ 45NhXqZyZhI4iC1vBQFab/FN2DPfT0o= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-116-yTGXHhqyOuasoBYvMB6zTw-1; Thu, 16 Jul 2026 03:22:47 -0400 X-MC-Unique: yTGXHhqyOuasoBYvMB6zTw-1 X-Mimecast-MFC-AGG-ID: yTGXHhqyOuasoBYvMB6zTw_1784186566 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-493bb6a4336so54619375e9.3 for ; Thu, 16 Jul 2026 00:22:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784186566; x=1784791366; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=fOPNiWWV4uOpdc8om2Cjbh3iGeqD9fn+Fr3qU77+7s0=; b=nJV8sqoaGrpxDtfm4HwZfm4UqyTqyv4B9gRBacPVHIS15f+Ex9ATfVuPYPSAnUJ7pD Y/mnMhdReSpk8qxHpApywupy436uO3LFLvc8LihKe5Q0OyHOgiF/LfkA+mPC0wB1O/sx zpckrH1UqxaK8IdlMYPs+xzH5do4F5Q4MvBrauj6BvAoh5eLintcOQJvFPrP5TjBYkj8 E+OFbruIDK74Svn3edmTsKBGlQ9itL4e8ZVe5yI2RFfQTf6gELTfdu7SztFPyTHuyqGa 8Fte12nW7uyfV+1qa4xbYoDl77Og3MAwatltsHpkqv6zAjZhYaIPxu9BcdmcldvTO2u/ fcSQ== X-Gm-Message-State: AOJu0Yy90DWdLqOesLU9U+dGRG1l6Fir8kg9Fst9FncOd+NtjFLyZzo7 C00PfgpdeiDmMk0UAtdT3zlPvAwKEny2T0u7U43qzityj/O+D0H3DxYSzGT7mxC+uBInAQNQJjV mavfpWyc5cA5LKoHaKuu7BTqthkQedCA0Rurh0SUsvN0Qge9Xaa51tiDZ08vXow== X-Gm-Gg: AfdE7clQVeBUrhrsr4NLXgHKYyGx2c2r5qzxhckuBP6TApxWCnpfoPu2z9Pr+5SjhDU majNPi2hiEeAMkSX00Hm0fnold4Se8HCIq/dDpR181w6ygXx6uWspnJr8Ic+X0cBANiwKvI8tem UhW4q/bkkuxpsSLg7gTT+bF9OUi9tNKkNPep+fqEtrZCUQipUxrONQxCVprhV+V8Au1Mq70UBLy 1Zoy8dnvT4Ttiwo7tZAcuybCou9bCvt3pxJdQPQFb6acmo9rQB6NerRbRQskuTASIVZYjGFS4zK gElTwgV13lX3MBnm+FF3sZQ9iHmKmd4/LiFG9vyaDmEy31api0FVXr9us0vEJ2p0ZI6R3jl88WO BWajlpg1NtZ/mCNcSEO6GFzOxsQUt X-Received: by 2002:a05:600c:530d:b0:495:3e08:ad24 with SMTP id 5b1f17b1804b1-4953e1919dcmr57840505e9.33.1784186566336; Thu, 16 Jul 2026 00:22:46 -0700 (PDT) X-Received: by 2002:a05:600c:530d:b0:495:3e08:ad24 with SMTP id 5b1f17b1804b1-4953e1919dcmr57840155e9.33.1784186565864; Thu, 16 Jul 2026 00:22:45 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49541e88ae9sm37857265e9.6.2026.07.16.00.22.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jul 2026 00:22:45 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 4/4] ndp: Use high quality entropy in NDP timer even if not needed Message-ID: <20260716092243.0ad556c4@elisabeth> In-Reply-To: References: <20260715232523.3372714-1-sbrivio@redhat.com> <20260715232523.3372714-5-sbrivio@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Thu, 16 Jul 2026 09:22:44 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Uq3jrAknYw1P3lew1n3l9m_-CBcDLZZCWb5IDyUeOqo_1784186566 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: MFO3JQGYRRCXNKUINEBFGPXDP3DQ7ATS X-Message-ID-Hash: MFO3JQGYRRCXNKUINEBFGPXDP3DQ7ATS X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, 16 Jul 2026 15:45:30 +1000 David Gibson wrote: > On Thu, Jul 16, 2026 at 01:25:23AM +0200, Stefano Brivio wrote: > > ...instead of calling random(), to make static checkers happy. > > > > I don't think that an attacker could actually gain anything by making > > router advertisement intervals predictable, but a doubt remains, and > > this is cheap enough that we might just want to do this to get rid of > > the noise from static checkers informing us that random() shouldn't be > > used. > > > > Signed-off-by: Stefano Brivio > > --- > > ndp.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/ndp.c b/ndp.c > > index 1f2bcb0..43457b3 100644 > > --- a/ndp.c > > +++ b/ndp.c > > @@ -413,6 +413,7 @@ void ndp_timer(const struct ctx *c, const struct timespec *now) > > { > > time_t max_rtr_adv_interval = DEFAULT_MAX_RTR_ADV_INTERVAL; > > time_t min_rtr_adv_interval, interval; > > + long random_part; > > > > if (!tap_is_ready(c) || c->no_ra || now->tv_sec < next_ra) > > return; > > @@ -433,15 +434,17 @@ void ndp_timer(const struct ctx *c, const struct timespec *now) > > * and causing flurries of RAs at the same time. > > * > > * This random doesn't need to be cryptographically strong, so random(3) > > - * is fine. Other routers on the link also want to avoid > > - * synchronisation, and anything malicious has much easier ways to cause > > - * trouble. > > + * would be fine. Other routers on the link also want to avoid > > + * synchronisation, and anything malicious would have much easier ways > > + * to cause trouble. However, for the sake of static checkers, use high > > + * quality entropy as provided by raw_random(). > > * > > * The modulus also makes this not strictly a uniform distribution, but, > > * again, it's close enough for our purposes. > > */ > > + raw_random(&random_part, sizeof(random_part)); > > interval = min_rtr_adv_interval + > > - random() % (max_rtr_adv_interval - min_rtr_adv_interval); > > + random_part % (max_rtr_adv_interval - min_rtr_adv_interval); > > Although it returns a signed long, random() is explicitly defined to > only return values between 0 and 2^31-1. Oops, I missed that part. I would have naturally used uint32_t here but then I looked (too quickly) at the prototype of random() and concluded it would be better to make it equivalent... except it's not. > Using raw_random() means we > can get anything in the full range of a 'long', including negative > numbers. Is that going to mess up our calculations here? I don't think in any catastrophic way, but it might, yes. > Might be safer to make random_part a uint32_t, then cast it to a > time_t for the arithmetic. Right, v2 does that. -- Stefano