From nobody Mon Oct 11 07:42:56 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C0E0917E7102 for ; Mon, 11 Oct 2021 07:43:05 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSW494gdHz3CRd; Mon, 11 Oct 2021 07:43:05 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy02.your-server.de ([78.47.166.47]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mZpxZ-000AOp-Jb; Mon, 11 Oct 2021 09:42:57 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZpxZ-000HJ0-GE; Mon, 11 Oct 2021 09:42:57 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1D57D48005F; Mon, 11 Oct 2021 09:42:57 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Q2yx82h-CnkK; Mon, 11 Oct 2021 09:42:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id BDCA048008B; Mon, 11 Oct 2021 09:42:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6FhR3Vj-9_Mn; Mon, 11 Oct 2021 09:42:56 +0200 (CEST) Received: from [10.10.171.10] (unknown [10.10.171.10]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 882F948005F; Mon, 11 Oct 2021 09:42:56 +0200 (CEST) Subject: Re: Why was the timehands_count sysctl added? To: Ian Lepore , Konstantin Belousov Cc: Warner Losh , FreeBSD Hackers References: <2d1d2a6d-ec6b-7f52-8af3-09a833c52820@embedded-brains.de> <1e7b3766007ed6e35ff9f75f680b2e786b4355f9.camel@freebsd.org> From: Sebastian Huber Message-ID: Date: Mon, 11 Oct 2021 09:42:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <1e7b3766007ed6e35ff9f75f680b2e786b4355f9.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.3/26318/Sun Oct 10 10:18:47 2021) X-Rspamd-Queue-Id: 4HSW494gdHz3CRd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 10/10/2021 19:44, Ian Lepore wrote: > On Sun, 2021-10-10 at 20:39 +0300, Konstantin Belousov wrote: >> On Sun, Oct 10, 2021 at 11:15:39AM -0600, Ian Lepore wrote: >>> On Sat, 2021-10-09 at 14:54 -0600, Warner Losh wrote: >>>> On Sat, Oct 9, 2021, 1:56 PM Konstantin Belousov >>>> >>>> wrote: >>>> >>>>> On Sat, Oct 09, 2021 at 09:41:28PM +0200, Sebastian Huber >>>>> wrote: >>>>>> Hello, >>>>>> >>>>>> I synchronize currently the port of the FreeBSD timecounters >>>>>> to >>>>>> RTEMS and >>>>>> came across a change in 2019 which I do not understand. Some >>>>>> time >>>>>> ago the >>>>>> timehands were reduced from 10 to two: >>>>>> >>>>>> https://reviews.freebsd.org/D7302 >>>>>> >>>>>> In 2019 this changed again to be up to 16: >>>>>> >>>>>> https://reviews.freebsd.org/D21563 >>>>> This review did not changed it back to 16, the default value is >>>>> still 2. >>>>> It allows to bump the number of used timehands, but normally >>>>> systems run >>>>> with only 2. >>>>> >>>>>> The corresponding sysctl is not documented: >>>>>> >>>>>> https://www.freebsd.org/cgi/man.cgi?query=3Dtimecounters&sektion=3D= 4 >>>>>> >>>>>> Does someone know why this sysctl to select the count of >>>>>> timehands was >>>>>> added? Is this a performance optimization for some systems? >>>>> To allow for experimentation, and to satisfy some requests >>>>> where >>>>> people >>>>> wanted to have more that 2 timehands. >>>>> >>>> When would someone want that? What's the use case? >>>> >>>> Warner >>>> >>> One known usecase is a single-cpu (non-SMP) system that uses a PPS >>> signal.=C2=A0 With only two timehands, a pps pulse that arrives while >>> the >>> system is in an idle-sleep (wait-for-interrupt) state will switch >>> timehands too many times between the wakeup and the capture and >>> trying >>> to use the capture data, so that the th generation count never >>> matches, >>> and in effect you never capture a PPS pulse.=C2=A0 I found that on a >>> BeagleBone system.=C2=A0 It takes a minimum of 3 timehands for it to >>> work >>> right. >> So should this system automatically adjust the number of timehands? >> There were no similar complaints on UP i386, at least I did not see >> them. >> > I think a required part of the failure scenario was a PPS driver that > used the hardware-capture feature (the hardware latches a counter on > the pps pulse and timecounter->tc_poll_pps() gets called to retrieve > the latched value). i386 hardware doesn't do that. The rareness of > the hardware that works that way (and the additional rareness of people > using that hardware that way) I think was part of why you made it > tunable rather than just increasing the timehands count for everyone, > back when I reported this scenario. Thanks for your insights. So in general the tunable timehands count is=20 an inexpensive knob which may fix issues under some very specific=20 conditions. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Mon Oct 11 07:53:31 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AC87517F1951 for ; Mon, 11 Oct 2021 07:53:34 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSWJF6jBdz3Gcy for ; Mon, 11 Oct 2021 07:53:33 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy02.your-server.de ([78.47.166.47]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mZq7o-000AkD-PV for freebsd-hackers@freebsd.org; Mon, 11 Oct 2021 09:53:32 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZq7o-000FSV-Mq for freebsd-hackers@freebsd.org; Mon, 11 Oct 2021 09:53:32 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 614DA48006A for ; Mon, 11 Oct 2021 09:53:32 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id e5OBzhuB5i0T for ; Mon, 11 Oct 2021 09:53:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 208A74800E2 for ; Mon, 11 Oct 2021 09:53:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uCMGOn6UxrEA for ; Mon, 11 Oct 2021 09:53:32 +0200 (CEST) Received: from [10.10.171.10] (unknown [10.10.171.10]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 0127648006A for ; Mon, 11 Oct 2021 09:53:31 +0200 (CEST) To: FreeBSD Hackers From: Sebastian Huber Subject: Large timecounter delta handling Message-ID: <5318327d-d247-bb73-81d9-967c4ae18d32@embedded-brains.de> Date: Mon, 11 Oct 2021 09:53:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.3/26318/Sun Oct 10 10:18:47 2021) X-Rspamd-Queue-Id: 4HSWJF6jBdz3Gcy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-1.28 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.969]; DMARC_NA(0.00)[embedded-brains.de]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I synchronize currently the port of the FreeBSD timecounters to RTEMS. I=20 have to write test cases for all code we use in RTEMS. In 2020 some code=20 was added to fix integer overflow issues with large time deltas while=20 getting the time from a timehand. https://github.com/freebsd/freebsd-src/commit/6cf2362e2c7e9061611f93a48ec= 654a5b7451d6b#diff-8b8e2f8e41e6a847f14ab08c7d50454c20a4a135f2c2241d91687c= 0832c1d99e If a time delta obtained by tc_delta(th) is greater than or equal to=20 th->th_large_delta, then some extra calculation is carried out. The th->th_large_delta is computed like this scale =3D (uint64_t)1 << 63; scale +=3D (th->th_adjustment / 1024) * 2199; scale /=3D th->th_counter->tc_frequency; th->th_scale =3D scale * 2; th->th_large_delta =3D MIN(((uint64_t)1 << 63) / scale, UINT_MAX); If we ignore the th->th_adjustment (=3D=3D 0), then we have ideally scale =3D 2**64 / f th->th_large_delta =3D MIN( f / 2, UINT_MAX ) Does this mean that we only need the large delta processing if a=20 timehand was not updated for about 0.5s? --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Mon Oct 11 08:58:24 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5ED5F17F7A1F for ; Mon, 11 Oct 2021 08:58:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSXlH0PrXz3LX7 for ; Mon, 11 Oct 2021 08:58:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19B8wOxa083459 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 11 Oct 2021 11:58:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19B8wOxa083459 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19B8wO7r083458; Mon, 11 Oct 2021 11:58:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Oct 2021 11:58:24 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: FreeBSD Hackers Subject: Re: Large timecounter delta handling Message-ID: References: <5318327d-d247-bb73-81d9-967c4ae18d32@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5318327d-d247-bb73-81d9-967c4ae18d32@embedded-brains.de> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HSXlH0PrXz3LX7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Oct 11, 2021 at 09:53:31AM +0200, Sebastian Huber wrote: > Hello, > > I synchronize currently the port of the FreeBSD timecounters to RTEMS. I > have to write test cases for all code we use in RTEMS. In 2020 some code was > added to fix integer overflow issues with large time deltas while getting > the time from a timehand. > > https://github.com/freebsd/freebsd-src/commit/6cf2362e2c7e9061611f93a48ec654a5b7451d6b#diff-8b8e2f8e41e6a847f14ab08c7d50454c20a4a135f2c2241d91687c0832c1d99e > > If a time delta obtained by tc_delta(th) is greater than or equal to > th->th_large_delta, then some extra calculation is carried out. > > The th->th_large_delta is computed like this > > scale = (uint64_t)1 << 63; > scale += (th->th_adjustment / 1024) * 2199; > scale /= th->th_counter->tc_frequency; > th->th_scale = scale * 2; > th->th_large_delta = MIN(((uint64_t)1 << 63) / scale, UINT_MAX); > > If we ignore the th->th_adjustment (== 0), then we have ideally > > scale = 2**64 / f > th->th_large_delta = MIN( f / 2, UINT_MAX ) > > Does this mean that we only need the large delta processing if a timehand > was not updated for about 0.5s? I do not understand your question. We need large_delta to handle overflows in bintime_off(). tc_large_delta is computed in advance during windup to avoid this calculation in time reading code. Your question is more like "under which conditions we switch to use tc_large_delta path in bintime_off()?" Then it is mostly right, that long intervals between tc_windup() calls would trigger it, and it seems that indeed it is around 0.5 sec. If you have a controlled environment, just skip some tc_windup() calls to see. From nobody Mon Oct 11 09:31:29 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2058317FDDD9 for ; Mon, 11 Oct 2021 09:31:32 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSYTJ06KLz3kSq for ; Mon, 11 Oct 2021 09:31:32 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy02.your-server.de ([78.47.166.47]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mZrec-000ESi-D2; Mon, 11 Oct 2021 11:31:30 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZrec-000Cx6-AK; Mon, 11 Oct 2021 11:31:30 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 09705480073; Mon, 11 Oct 2021 11:31:30 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5ssTeo40jPco; Mon, 11 Oct 2021 11:31:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id ACBF7480074; Mon, 11 Oct 2021 11:31:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R3KRQW76XwJW; Mon, 11 Oct 2021 11:31:29 +0200 (CEST) Received: from [10.10.171.10] (unknown [10.10.171.10]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 77D4B480073; Mon, 11 Oct 2021 11:31:29 +0200 (CEST) Subject: Re: Large timecounter delta handling To: Konstantin Belousov Cc: FreeBSD Hackers References: <5318327d-d247-bb73-81d9-967c4ae18d32@embedded-brains.de> From: Sebastian Huber Message-ID: <994a76c2-4ea6-bfdc-bbe5-0795cf8fd4ee@embedded-brains.de> Date: Mon, 11 Oct 2021 11:31:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.3/26319/Mon Oct 11 10:18:47 2021) X-Rspamd-Queue-Id: 4HSYTJ06KLz3kSq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/10/2021 10:58, Konstantin Belousov wrote: > On Mon, Oct 11, 2021 at 09:53:31AM +0200, Sebastian Huber wrote: >> Hello, >> >> I synchronize currently the port of the FreeBSD timecounters to RTEMS.= I >> have to write test cases for all code we use in RTEMS. In 2020 some co= de was >> added to fix integer overflow issues with large time deltas while gett= ing >> the time from a timehand. >> >> https://github.com/freebsd/freebsd-src/commit/6cf2362e2c7e9061611f93a4= 8ec654a5b7451d6b#diff-8b8e2f8e41e6a847f14ab08c7d50454c20a4a135f2c2241d916= 87c0832c1d99e >> >> If a time delta obtained by tc_delta(th) is greater than or equal to >> th->th_large_delta, then some extra calculation is carried out. >> >> The th->th_large_delta is computed like this >> >> scale =3D (uint64_t)1 << 63; >> scale +=3D (th->th_adjustment / 1024) * 2199; >> scale /=3D th->th_counter->tc_frequency; >> th->th_scale =3D scale * 2; >> th->th_large_delta =3D MIN(((uint64_t)1 << 63) / scale, UINT_MAX); >> >> If we ignore the th->th_adjustment (=3D=3D 0), then we have ideally >> >> scale =3D 2**64 / f >> th->th_large_delta =3D MIN( f / 2, UINT_MAX ) >> >> Does this mean that we only need the large delta processing if a timeh= and >> was not updated for about 0.5s? >=20 > I do not understand your question. We need large_delta to handle overf= lows > in bintime_off(). tc_large_delta is computed in advance during windup = to > avoid this calculation in time reading code. Yes, I also ask since we never got bug reports for RTEMS related to such=20 a scenario. No updates for about 0.5s would mean that an RTEMS=20 application is already in a completely undefined system state. Maybe it=20 can happen in FreeBSD systems under transient overload conditions. It could happen in RTEMS, if we have an extremely long boot time, since=20 during boot interrupts are disabled. >=20 > Your question is more like "under which conditions we switch to use > tc_large_delta path in bintime_off()?" Then it is mostly right, that > long intervals between tc_windup() calls would trigger it, and it seems > that indeed it is around 0.5 sec. Yes, this was the question. I think the initialization value should be 50000: diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 81d373b3b1d0..a4792e31abd4 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -87,7 +87,7 @@ static struct timehands ths[16] =3D { [0] =3D { .th_counter =3D &dummy_timecounter, .th_scale =3D (uint64_t)-1 / 1000000, - .th_large_delta =3D 1000000, + .th_large_delta =3D 500000, .th_offset =3D { .sec =3D 1 }, .th_generation =3D 1, }, >=20 > If you have a controlled environment, just skip some tc_windup() calls > to see. Yes, I can also use a software timecounter for these tests. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Mon Oct 11 09:43:57 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D9BF017FF332 for ; Mon, 11 Oct 2021 09:44:00 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSYlh0XQjz3m33 for ; Mon, 11 Oct 2021 09:44:00 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy02.your-server.de ([78.47.166.47]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mZrqg-000ErV-F9; Mon, 11 Oct 2021 11:43:58 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZrqg-000QAe-C6; Mon, 11 Oct 2021 11:43:58 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 10741480084; Mon, 11 Oct 2021 11:43:58 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ws7OViLgUSqR; Mon, 11 Oct 2021 11:43:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A8A3848009D; Mon, 11 Oct 2021 11:43:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IcXYShIdNXTi; Mon, 11 Oct 2021 11:43:57 +0200 (CEST) Received: from [10.10.171.10] (unknown [10.10.171.10]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 74665480084; Mon, 11 Oct 2021 11:43:57 +0200 (CEST) Subject: Re: Large timecounter delta handling From: Sebastian Huber To: Konstantin Belousov Cc: FreeBSD Hackers References: <5318327d-d247-bb73-81d9-967c4ae18d32@embedded-brains.de> <994a76c2-4ea6-bfdc-bbe5-0795cf8fd4ee@embedded-brains.de> Message-ID: <302debc8-2888-228a-b009-1bade543fb9a@embedded-brains.de> Date: Mon, 11 Oct 2021 11:43:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <994a76c2-4ea6-bfdc-bbe5-0795cf8fd4ee@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.3/26319/Mon Oct 11 10:18:47 2021) X-Rspamd-Queue-Id: 4HSYlh0XQjz3m33 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-1.32 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; NEURAL_SPAM_SHORT(0.98)[0.979]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/10/2021 11:31, Sebastian Huber wrote: >> Your question is more like "under which conditions we switch to use >> tc_large_delta path in bintime_off()?"=C2=A0 Then it is mostly right, = that >> long intervals between tc_windup() calls would trigger it, and it seem= s >> that indeed it is around 0.5 sec. >=20 > Yes, this was the question. >=20 > I think the initialization value should be 50000: >=20 > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > index 81d373b3b1d0..a4792e31abd4 100644 > --- a/sys/kern/kern_tc.c > +++ b/sys/kern/kern_tc.c > @@ -87,7 +87,7 @@ static struct timehands ths[16] =3D { > =C2=A0=C2=A0=C2=A0=C2=A0 [0] =3D=C2=A0 { > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .th_counter =3D &dummy_time= counter, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .th_scale =3D (uint64_t)-1 = / 1000000, > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .th_large_delta =3D 1000000, > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .th_large_delta =3D 500000, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .th_offset =3D { .sec =3D 1= }, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .th_generation =3D 1, > =C2=A0=C2=A0=C2=A0=C2=A0 }, No, sorry. The existing code is correct. I miscalculated the large delta=20 by using th->th_scale for "scale" in th->th_large_delta =3D MIN(((uint64_t)1 << 63) / scale, UINT_MAX); which is th->th_scale =3D scale * 2; --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Mon Oct 11 15:50:31 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C5F9317F5181 for ; Mon, 11 Oct 2021 15:50:40 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4HSjtm1JsCz3L3x for ; Mon, 11 Oct 2021 15:50:40 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Received: from yv.noip.me (c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 19BFoWNA000869 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 11 Oct 2021 08:50:33 -0700 (PDT) (envelope-from yuri@FreeBSD.org) X-Authentication-Warning: shell1.rawbw.com: Host c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76] claimed to be yv.noip.me To: Freebsd hackers list From: Yuri Subject: Possible to start the process with setuid while allowing it to listen on privileged ports? Message-ID: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> Date: Mon, 11 Oct 2021 08:50:31 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4HSjtm1JsCz3L3x X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US] X-ThisMailContainsUnwantedMimeParts: N Normal way to do this is for the application to first listen on the port and then setuid. My question is about the situation when the application isn't willing to do this. The project author says that setuid is too difficult in Go and Linux allows to do this through systemd: https://github.com/coredns/coredns/issues/4917#issuecomment-939892548 Can in FreeBSD the process be run as a regular user but still be allowed to bind to privileged ports? Thanks, Yuri From nobody Mon Oct 11 15:56:22 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1C3A417F8AC0 for ; Mon, 11 Oct 2021 15:56:36 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSk1b4W81z3NvL; Mon, 11 Oct 2021 15:56:35 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 19BFuMqE064808; Mon, 11 Oct 2021 08:56:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Mon, 11 Oct 2021 08:56:22 -0700 From: Chris To: Yuri Cc: Freebsd hackers list Subject: Re: Possible to start the process with setuid while allowing it to listen on privileged ports? In-Reply-To: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> References: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> User-Agent: UDNSMS/17.0 Message-ID: <1db5aa695aac2b6a0b5bf4bd3b553af5@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HSk1b4W81z3NvL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2021-10-11 08:50, Yuri wrote: > Normal way to do this is for the application to first listen on the port and > then setuid. > > > My question is about the situation when the application isn't willing to do > this. > > > The project author says that setuid is too difficult in Go and Linux allows > to do > this through systemd: > > https://github.com/coredns/coredns/issues/4917#issuecomment-939892548 > > > Can in FreeBSD the process be run as a regular user but still be allowed to > bind > to privileged ports? Doesn't (X)org do this? If I'm right, maybe there's a clue there? HTH --Chris > > > Thanks, > > Yuri From nobody Mon Oct 11 16:21:46 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 00A7A18021DA for ; Mon, 11 Oct 2021 16:21:58 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSkZs0LNVz3mHq for ; Mon, 11 Oct 2021 16:21:56 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DA8E63200D78 for ; Mon, 11 Oct 2021 12:21:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 11 Oct 2021 12:21:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=n FC9M4Xost6bUkUuIPw6uTxHyeyjkonxDf76Ww3HPIc=; b=mOeJwQbt+2b2shYcr O2KhIWnaPFgh8pnp1BQ3hjGotvfVRXhLpyfsUyXK0OW5SD2abDTg9raYMSyjqYff aIL/xOpnAzhfz4vYDZMK9uktqMawmKUZjIX6Nt4lJj85lSeuAsFC75hxLtw6Kh2Z ZvKrhihLZOK2bS3vFMjcKS8HgAas+TgAFt8+9zqSRBISvjZfP1vwqKBwSRn2nbZ7 8W05TOn4rBcrD0lbWYgl1R7QSCNBVc64PhD4A8QvvQ190kAZnCTDAZ44eYY2MnNT tNOhb5LsQVLC6PogUKhkCuJR+coLuskGeaNqhMG4CzLPRG4vTlftFrE2AF0CPeXu v1hdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=nFC9M4Xost6bUkUuIPw6uTxHyeyjkonxDf76Ww3HP Ic=; b=deVPh8VPHJ3HoiHkLjadEwMogFRZF4vaTQrIm22zVHCFdgXXTLw96pINQ RUFK5feqqE1k4dvsIQFr6nr5BQgx3A2HsvZXIHjm/EiPKnrfmjwSBbe6KD0abl3u N6JFcy8cqPlTWdXe3dfbCrZX+qmzD1iQJ5wn+AfDkvcrIavTepsX4mgJTg9MkXao 3nALYegDj+8qHk2anJlUUIxY0BzCBxe0/3D9QabwA/QHWNnEHS5B9exg2VsDIxC+ gvIc/GW0XnURu6dAxDMyno5okw+6STG3P+66pgqA8OQgKyWXoqN1YldGvG5ayDiO wfvvdcwpHv54FT5juzAoLT/AL0+5w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtiedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepjghurhhi uceohihurhhisegrvghtvghrnhdrohhrgheqnecuggftrfgrthhtvghrnhepueelgfeufe dtvdeiveektdejueekgffgvedtteettdeuleeuudffvedukeekudfgnecuffhomhgrihhn pehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpeihuhhrihesrggvthgvrhhnrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 11 Oct 2021 12:21:48 -0400 (EDT) Message-ID: Date: Mon, 11 Oct 2021 19:21:46 +0300 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: Possible to start the process with setuid while allowing it to listen on privileged ports? Content-Language: en-US To: Freebsd hackers list References: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> From: Yuri In-Reply-To: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HSkZs0LNVz3mHq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm1 header.b=mOeJwQbt; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=deVPh8VP; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.24 as permitted sender) smtp.mailfrom=yuri@aetern.org X-Spamd-Result: default: False [-3.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[aetern.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N Yuri wrote: > Normal way to do this is for the application to first listen on the port > and then setuid. > > > My question is about the situation when the application isn't willing to > do this. > > > The project author says that setuid is too difficult in Go and Linux > allows to do this through systemd: > > https://github.com/coredns/coredns/issues/4917#issuecomment-939892548 > > > Can in FreeBSD the process be run as a regular user but still be allowed > to bind to privileged ports? Quoting ip(4): --- The range of privileged ports which only may be opened by root-owned processes may be modified by the net.inet.ip.portrange.reservedlow and net.inet.ip.portrange.reservedhigh sysctl settings. The values default to the traditional range, 0 through IPPORT_RESERVED-1 (0 through 1023), respectively. Note that these settings do not affect and are not accounted for in the use or calculation of the other net.inet.ip.portrange values above. Changing these values departs from UNIX tradition and has security consequences that the administrator should carefully evaluate before modifying these settings. --- From nobody Mon Oct 11 16:24:37 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 444171804D33 for ; Mon, 11 Oct 2021 16:24:44 +0000 (UTC) (envelope-from maxim@maxim.int.ru) Received: from maxim.int.ru (maxim.int.ru [167.71.75.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "maxim.int.ru", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSkf40BXNz3pBx; Mon, 11 Oct 2021 16:24:43 +0000 (UTC) (envelope-from maxim@maxim.int.ru) Received: from localhost (maxim@localhost [127.0.0.1]) by maxim.int.ru (8.16.1/8.16.1) with ESMTPS id 19BGObBk080222 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 11 Oct 2021 16:24:37 GMT (envelope-from maxim@maxim.int.ru) Date: Mon, 11 Oct 2021 16:24:37 +0000 (UTC) From: Maxim Konovalov To: Yuri cc: Freebsd hackers list Subject: Re: Possible to start the process with setuid while allowing it to listen on privileged ports? In-Reply-To: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> Message-ID: References: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4HSkf40BXNz3pBx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 11 Oct 2021, 08:50-0700, Yuri wrote: > Normal way to do this is for the application to first listen on the port and > then setuid. > > My question is about the situation when the application isn't willing to do > this. > > The project author says that setuid is too difficult in Go and Linux allows to > do this through systemd: > > https://github.com/coredns/coredns/issues/4917#issuecomment-939892548 > > Can in FreeBSD the process be run as a regular user but still be allowed to > bind to privileged ports? > This could be possible to implement with mac_portacl(4). -- Maxim Konovalov From nobody Mon Oct 11 18:41:23 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3FB8C17F53D5 for ; Mon, 11 Oct 2021 18:41:32 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSngv24f7z3RBq for ; Mon, 11 Oct 2021 18:41:31 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 079B15C0056 for ; Mon, 11 Oct 2021 14:41:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 11 Oct 2021 14:41:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=q F5Ztm7eYCOcGhQwP0qsXQXiaXkNp41iUPp3wXw8WGM=; b=duz7op3bFw+o4hWZR nXrlICZW4l42AXlkBomBdmX1YKgObmHNdLsFgW/Fws48vfQIsE1cgKfRNMmkZFvb coxw4MWnaOhaFNCxK3gbq5GJAyK20mSL8BNk7KsATYou3pDxXSv2lm2I284eTyNT StZoYcOHt0JzzfAk1RP7f0idXQie0zfqE5crIPIHypHPDmmNwZlt+aMCe6i8OgCl P3nMbsmQeOZx40qW1lMHFFYg2tjr8npSs6Y4Q+/Ot8BEqZ8OMXtNxWXUKSOx6uIf B3j7Ip1BlhjHtHNhYpqhtXsYskWyhSe1iX/lwebJ6tDawwe5SEb5PN9a1l3BeSd+ L2eEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qF5Ztm7eYCOcGhQwP0qsXQXiaXkNp41iUPp3wXw8W GM=; b=nJnp24uIXMVswLqHhS9HnsWdeI3iiW3ZeRGpdZ6MATRKTJ6XOFAz36r+a LnonJWBsNZzliOK69vFWIqXdPdxMxsBUrnvaS6nxUFlSi68XvNaEBJ1EkQtNMEl0 uTRRdczriisxYrkdIeOxXkYN/nDoozqVh296zWiVoduGddQoP4IPG2aWNyxxL6FL jKAJ6ir1qTZgZMuPwuwKwcBO5j9R/sAmfIB3T1PZ9UB2hlJZJl1Te6OVWSC0UdGc p4sGjssgyNCnWNXR5XV1i7YpB3yZjjhJBL9SRD+m2dLrMHPAEEDf7WnmeCVMwssg +Pvykv3/nTPwVDOzLX0BDKTh/60QQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtiedguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesth ejredttdefjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheq necuggftrfgrthhtvghrnhepffevvdeikefgudfgudekueekvdejieehteevtdehjeevfe eigeeghfdvgfelteegnecuffhomhgrihhnpehgihhthhhusgdrtghomhdprhgvshgvrhhv vgguhhhighhhrddqqddqihhnnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhephihurhhisegrvghtvghrnhdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 11 Oct 2021 14:41:24 -0400 (EDT) Message-ID: <774b0a05-c67e-89b9-885d-1a6e1212ee9c@aetern.org> Date: Mon, 11 Oct 2021 21:41:23 +0300 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: Possible to start the process with setuid while allowing it to listen on privileged ports? Content-Language: en-US To: hackers@freebsd.org References: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> From: Yuri In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HSngv24f7z3RBq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm1 header.b=duz7op3b; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=nJnp24uI; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.25 as permitted sender) smtp.mailfrom=yuri@aetern.org X-Spamd-Result: default: False [-3.52 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.92)[-0.923]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.0.0/20, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; DMARC_NA(0.00)[aetern.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Maxim Konovalov wrote: > On Mon, 11 Oct 2021, 08:50-0700, Yuri wrote: > >> Normal way to do this is for the application to first listen on the port and >> then setuid. >> >> My question is about the situation when the application isn't willing to do >> this. >> >> The project author says that setuid is too difficult in Go and Linux allows to >> do this through systemd: >> >> https://github.com/coredns/coredns/issues/4917#issuecomment-939892548 >> >> Can in FreeBSD the process be run as a regular user but still be allowed to >> bind to privileged ports? >> > This could be possible to implement with mac_portacl(4). mac_portacl(4) seems to be limited by the sysctls I mentioned in another reply: --- port Describes which port this entry applies to. NOTE: MAC security policies may not override other security system policies by allowing accesses that they may deny, such as net.inet.ip.portrange.reservedlow / net.inet.ip.portrange.reservedhigh. --- In addition to linux/systemd, solaris also allows this through its privilege framework (PRIV_NET_PRIVADDR). Wonder if we have something similar? From nobody Tue Oct 12 02:07:10 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 429FE1803A77 for ; Tue, 12 Oct 2021 02:07:18 +0000 (UTC) (envelope-from chris.stephan@live.com) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10olkn2080e.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e89::80e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSzZG07STz3qG2 for ; Tue, 12 Oct 2021 02:07:17 +0000 (UTC) (envelope-from chris.stephan@live.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SCbH+0zgbFCm4fO3Ut3EPkngFTbZ8gVs653Hk58igcWVYp9ARKfJQX3pMDh/ZLKGEIybNv7SsnHfyhuZALF8YczGGR2reuiAdVRLm9Qg94xUh/Wn4EAsFE+fbqL4nqUks5p6/6wBHIZ2QGZM0+A5oYtxo6gZ1tG/B/qt0eatssBbjQ3kAzPTiLx6zzSjWGib1czfzyh2fLdXSgaSVl8tGooslSXP03T75lJRKHXQN4Gf7FOhD+ch8qg5pNvKEK7Mql1FSCPoY5dC2waXJu51vMeoveJNoELfxItoPCFLSXnX/qKl3bX3ya1Z2sSS/SZJKFWfvne5wiOHgpzoAskpgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7kfbvwAuALztOZZPl/irC5ICzCwfoRDV23eSnxdSLzU=; b=ZEvcosCwYFTFhrAsA2XP+tBsA9z5yBfTd0Qvxp4NubG4tn9IKjD51FMhHFvf8TJhDTWDPRWtYnFZKgoktuuRbaeNqqr0Jlq4XV0fALEZs6atdMiZdDleNgBqmQRo+H3hGhzYwgHq/O92J/XEjFWWRztf6Hjz8B0so93sZj7zyf2LrrBllCplZev9AT5BHy4jZSdQYYTKZcGJwPoEMxBcz1uE2CQzpu4J7IuquPnOKw+boRhRPOf/gIpfAuwbO410ZIKk7v6GVHm6y+gNLnC2pGs0FbpTmW2MW66rnCYoHNRJRQWj33MaWmsJbTEXnsFy5pV2qXCGuj+i5XS6dAb9aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7kfbvwAuALztOZZPl/irC5ICzCwfoRDV23eSnxdSLzU=; b=mRZc680JQa7yIsxPYcdGZgK8i95M0ltNGvL5VXiEaFhWJQLiv/l8opp/RHXpmM29Ei5A7QIhozvQEUIJgDIgt4WU9hXGcKpoJ82aFuLbxaP7wIbjuFbKdqspmSILw6gGPwTPumIjsUJAXCLFAuRkW587VBtD0dFu6iedx/qYwg93Q3eK4VYi86Zv8n32bgD2m5zl9IC/d8g4anyOS73rT3V6HB3UwGR960nK6Z5ktu6P90zf5aeeS4ADJYxTVNhDVgEZaGq892FCqiBIuQh1yBMGRzVlWPkH9o5C00LS5Lyp/Bznz2eOG7gdFuo0UQ5oKLjzkLuKXTJt471X43qn3g== Received: from SA1PR02MB8669.namprd02.prod.outlook.com (2603:10b6:806:1fc::12) by SA0PR02MB7194.namprd02.prod.outlook.com (2603:10b6:806:d9::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Tue, 12 Oct 2021 02:07:10 +0000 Received: from SA1PR02MB8669.namprd02.prod.outlook.com ([fe80::b144:e19c:19e8:b7c7]) by SA1PR02MB8669.namprd02.prod.outlook.com ([fe80::b144:e19c:19e8:b7c7%7]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 02:07:10 +0000 From: Chris Stephan To: Yuri CC: "hackers@freebsd.org" Subject: Re: Possible to start the process with setuid while allowing it to listen on privileged ports? Thread-Topic: Possible to start the process with setuid while allowing it to listen on privileged ports? Thread-Index: AQHXvrf3b5uZgwyhrkqG/GLRYm9ItqvN+4eAgAAmNoCAAHyNng== Date: Tue, 12 Oct 2021 02:07:10 +0000 Message-ID: References: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> <774b0a05-c67e-89b9-885d-1a6e1212ee9c@aetern.org> In-Reply-To: <774b0a05-c67e-89b9-885d-1a6e1212ee9c@aetern.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [xnySn1nofAWc6rEm59XPHTnoeXlNiAXx] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a3c3a2c4-000b-4606-38b7-08d98d25004c x-ms-traffictypediagnostic: SA0PR02MB7194: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6YD1+evGa6DniSRp5AdClt1I6VRhKA6qmzDOUIqo4qS+ltdGFZwtlkvm2dQq8KlJlEL9Pach/32k4HrUTuIhhc1KjyJTUaJJhoUpgl0uhHeRxEsTtdRJZ2tj007Oxg4CXUJrWNcslkGUUKfxUUS5PIiOq0VpsUTygu5Q+pOiXKdLzkHj6iP5NHRzF6uZDeH48kPO+QPwj/VdZ6618maKk0pSEvYAEoEYX0RDa54RzvZp6icc1fcplC+aUuG+U7ZyPDimD67/THnD1T2uQnaaOPUeVWq/3lEV3L/ZW52aIsl6JbQMroXXlwb0HR7V4FQoreOyBn9b+9t6Wq8r0t1KKUID0+9QQfduxF95J4coKkYYnbtvOZ5Gvo4o43Qoog49Moaf86+268mACsyEUWG/R8M/wQxBe3bmDoQXblIgb1EfQMcU/PqtWLwdpy6paZR3OWFk2/Msx1C1Y/bNgLaKo6pI7bKQxhc8VI/SFJa22S4= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: /apITDcv6qeEBaPyG5IZD3ZvFZGYKvh+aFxYTXpIwry4eXnLalLB2FMIvkrgeC86Gs62qT8OiibTQrJrtcJkoi9O1knC5lPXIb5tPvL+ulHs02jaTIGAFWLqEe8VpoHUjV0brLNZyXLtwLq6hlMDTA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA1PR02MB8669B47BF860056FFC223B409BB69SA1PR02MB8669namp_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-cec7a.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR02MB8669.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: a3c3a2c4-000b-4606-38b7-08d98d25004c X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 02:07:10.7131 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR02MB7194 X-Rspamd-Queue-Id: 4HSzZG07STz3qG2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --_000_SA1PR02MB8669B47BF860056FFC223B409BB69SA1PR02MB8669namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBpcyBob3cgd2Ugc29sdmUgdGhpcyBwcm9ibGVtLg0KDQpGaXJzdCwgaXTigJlzIGFsd2F5 cyB3aXNlIHRvIHJ1biBhIGZpcmV3YWxsIG9uIHRoZSBzeXN0ZW0sIFBGLCBJUEYsIG9yIElQRlcs IGV0Y+KApiBhdCB0aGUgdmVyeSBsZWFzdCBzaW5jZSB3ZSBhcmUgcmVtb3ZpbmcgdGhlIHByZXN1 bWVkIHNlY3VyaXR5IG1lY2hhbmlzbSBwcm92aWRlZCBieSByb290IGJpbmQgbGltaXQgb24gbG93 ZXIgcG9ydHMuIFRoZSBmaXJld2FsbCB3aWxsIHByb3ZpZGUgYSBnb29kIGF1ZGl0IHRyYWlsLCBh bmQgcHJvdmlkZSBhIGNoZWNrIGFuZCBiYWxhbmNlIGFnYWluc3QgdGhlIHBlcm1pc3Npb25zIHBy b3ZpZGVkIGJ5IG1hY19wb3J0YWNsIGZyYW1ld29yaw0KDQpBc3N1bWluZyB0aGUgYWJvdmUsIHRo ZSBmb2xsb3dpbmcgd29ya3MgZmxhd2xlc3NseS4NCg0KbG9hZGVyLmNvbmYoNSk8aHR0cHM6Ly93 d3cuZnJlZWJzZC5vcmcvY2dpL21hbi5jZ2k/cXVlcnk9bG9hZGVyLmNvbmYmc2VrdGlvbj01JmFw cm9wb3M9MCZtYW5wYXRoPUZyZWVCU0QrMTMuMC1SRUxFQVNFK2FuZCtQb3J0cz46DQoNCm1hY19w b3J0YWNsX2xvYWQ9IllFUyINCg0KbmV0LmluZXQuaXAucG9ydHJhbmdlLnJlc2VydmVkbG93PTAN Cg0Kc2VjdXJpdHkubWFjLnBvcnRhY2wucG9ydF9oaWdoPTEwMjMNCg0Kc2VjdXJpdHkubWFjLnBv cnRhY2wuZW5hYmxlZD0xDQoNCk5vdywgeW91IHNwZWNpZnkgdGhlIHNlY3VyaXR5Lm1hYy5wb3J0 YWNsLnJ1bGVzIFJlcXVpcmVkIHRvIHN1cHBvcnQgdGhlIHVzZSBjYXNlLiBUaGUgdHJpY2sgaW4g dGhlIGFib3ZlIGlzIGJ5IHNldHRpbmcgdGhlIHJlc2VydmVkbG93IHBvcnQgdG8gMCBhbmQgcG9y dCBoaWdoIHRvIDEwMjMsIHdlIGFyZSB0ZWxsaW5nIHRoZSBtYWNfcG9ydGFjbCBmcmFtZXdvcmsg aXQgaXMgaW4gY29tcGxldGUgY29udHJvbCBvZiBub24gcm9vdCBiaW5kaW5nIGZvciBwb3J0cyAw LTEwMjMgYXMgb3Bwb3NlZCB0byByZWx5aW5nIG9uIHRoZSBpbXBsaWNpdCBsaW1pdHMgcHJvdmlk ZWQgYnkgdGhlIOKAnG11c3QgYmUgcm9vdCB0byBiaW5k4oCcIG1ldGhvZG9sb2d5IGluaGVyZW50 IGluIHRyYWRpdGlvbmFsIFVOSVjigJlzLg0KDQpUaGFua3MsDQoNCkNocmlzDQoNClNlbnQgZnJv bSBGcmVlQlNEDQoNCk9uIE9jdCAxMSwgMjAyMSwgYXQgMTo0MiBQTSwgWXVyaSA8eXVyaUBhZXRl cm4ub3JnPiB3cm90ZToNCg0K77u/TWF4aW0gS29ub3ZhbG92IHdyb3RlOg0KT24gTW9uLCAxMSBP Y3QgMjAyMSwgMDg6NTAtMDcwMCwgWXVyaSB3cm90ZToNCg0KTm9ybWFsIHdheSB0byBkbyB0aGlz IGlzIGZvciB0aGUgYXBwbGljYXRpb24gdG8gZmlyc3QgbGlzdGVuIG9uIHRoZSBwb3J0IGFuZA0K dGhlbiBzZXR1aWQuDQoNCk15IHF1ZXN0aW9uIGlzIGFib3V0IHRoZSBzaXR1YXRpb24gd2hlbiB0 aGUgYXBwbGljYXRpb24gaXNuJ3Qgd2lsbGluZyB0byBkbw0KdGhpcy4NCg0KVGhlIHByb2plY3Qg YXV0aG9yIHNheXMgdGhhdCBzZXR1aWQgaXMgdG9vIGRpZmZpY3VsdCBpbiBHbyBhbmQgTGludXgg YWxsb3dzIHRvDQpkbyB0aGlzIHRocm91Z2ggc3lzdGVtZDoNCg0KaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29t JTJGY29yZWRucyUyRmNvcmVkbnMlMkZpc3N1ZXMlMkY0OTE3JTIzaXNzdWVjb21tZW50LTkzOTg5 MjU0OCZhbXA7ZGF0YT0wNCU3QzAxJTdDJTdDMzE4ZWIxMWJlMzU1NDczYTcyYzYwOGQ5OGNlNmVj NTQlN0M4NGRmOWU3ZmU5ZjY0MGFmYjQzNWFhYWFhYWFhYWFhYSU3QzElN0MwJTdDNjM3Njk1NzQ1 NzE5NzE0NjczJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENK UUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3Nk YXRhPVBvS2xxcGVSS3k0bnR5Um1Ea294M1F0NWFPOXFIblpvc25EWGswYk5QdzglM0QmYW1wO3Jl c2VydmVkPTANCg0KQ2FuIGluIEZyZWVCU0QgdGhlIHByb2Nlc3MgYmUgcnVuIGFzIGEgcmVndWxh ciB1c2VyIGJ1dCBzdGlsbCBiZSBhbGxvd2VkIHRvDQpiaW5kIHRvIHByaXZpbGVnZWQgcG9ydHM/ DQoNClRoaXMgY291bGQgYmUgcG9zc2libGUgdG8gaW1wbGVtZW50IHdpdGggbWFjX3BvcnRhY2wo NCkuDQoNCm1hY19wb3J0YWNsKDQpIHNlZW1zIHRvIGJlIGxpbWl0ZWQgYnkgdGhlIHN5c2N0bHMg SSBtZW50aW9uZWQgaW4gYW5vdGhlcg0KcmVwbHk6DQotLS0NCiAgICBwb3J0ICAgICAgICAgIERl c2NyaWJlcyB3aGljaCBwb3J0IHRoaXMgZW50cnkgYXBwbGllcyB0by4gIE5PVEU6DQogICAgICAg ICAgICAgICAgICBNQUMgc2VjdXJpdHkgcG9saWNpZXMgbWF5IG5vdCBvdmVycmlkZSBvdGhlcg0K ICAgICAgICAgICAgICAgICAgc2VjdXJpdHkgc3lzdGVtIHBvbGljaWVzIGJ5IGFsbG93aW5nIGFj Y2Vzc2VzIHRoYXQNCiAgICAgICAgICAgICAgICAgIHRoZXkgbWF5IGRlbnksIHN1Y2ggYXMNCiAg ICAgICAgICAgICAgICAgIG5ldC5pbmV0LmlwLnBvcnRyYW5nZS5yZXNlcnZlZGxvdyAvDQogICAg ICAgICAgICAgICAgICBuZXQuaW5ldC5pcC5wb3J0cmFuZ2UucmVzZXJ2ZWRoaWdoLg0KLS0tDQoN CkluIGFkZGl0aW9uIHRvIGxpbnV4L3N5c3RlbWQsIHNvbGFyaXMgYWxzbyBhbGxvd3MgdGhpcyB0 aHJvdWdoIGl0cw0KcHJpdmlsZWdlIGZyYW1ld29yayAoUFJJVl9ORVRfUFJJVkFERFIpLiAgV29u ZGVyIGlmIHdlIGhhdmUgc29tZXRoaW5nDQpzaW1pbGFyPw0KDQo= --_000_SA1PR02MB8669B47BF860056FFC223B409BB69SA1PR02MB8669namp_-- From eugen@grosbein.net Tue Oct 12 02:24:26 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1C648180B39B for ; Tue, 12 Oct 2021 02:24:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSzyL5sMkz3vwV; Tue, 12 Oct 2021 02:24:42 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 19C2OY5F051805 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Oct 2021 02:24:34 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: yuri@FreeBSD.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 19C2OXsD071878 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 12 Oct 2021 09:24:33 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Possible to start the process with setuid while allowing it to listen on privileged ports? To: Yuri , Freebsd hackers list References: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> From: Eugene Grosbein Message-ID: Date: Tue, 12 Oct 2021 09:24:26 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <6e98975c-34e5-246f-5b86-700b5f847815@rawbw.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4HSzyL5sMkz3vwV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N 11.10.2021 22:50, Yuri wrote: > Normal way to do this is for the application to first listen on the port and then setuid. > > > My question is about the situation when the application isn't willing to do this. > > > The project author says that setuid is too difficult in Go and Linux allows to do this through systemd: > > https://github.com/coredns/coredns/issues/4917#issuecomment-939892548 > > > Can in FreeBSD the process be run as a regular user but still be allowed to bind to privileged ports? Yes, of course. We have mac_portacl(4) since FreeBSD 8 just for that task. There is sysctl net.inet.ip.portrange.reservedhigh=1023 by default that defines "privileged low port" protection for super-user. Kernel module mac_portacl provides sysctl security.mac.portacl.port_high=1023 by default that duplicates this protection, so you should disable first one after loading mac_portacl with sysctl net.inet.ip.portrange.reservedhigh=0. Unprivileged users still cannot bind to low ports unless specifically granted that right with another sysctl, for example: security.mac.portacl.rules=uid:53:tcp:53,uid:53:udp:53 This is "real life" example for ISC BIND running with UID 53 that allows it to bind tcp/53 and udp/53 for dynamically created interfaces like tun/tap/ng/eiface etc. when BIND runs as non-root.