From nobody Tue Mar 19 00:46:36 2024 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 4TzCj51NMRz5FMFX for ; Tue, 19 Mar 2024 00:46:49 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TzCj34fPkz4qSS for ; Tue, 19 Mar 2024 00:46:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 81B5D8D4A217 for ; Tue, 19 Mar 2024 00:46:38 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2E5542D029D8 for ; Tue, 19 Mar 2024 00:46:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id V8ZBec7Ru9gG for ; Tue, 19 Mar 2024 00:46:37 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 25C092D029D2 for ; Tue, 19 Mar 2024 00:46:37 +0000 (UTC) Date: Tue, 19 Mar 2024 00:46:36 +0000 (UTC) From: "Bjoern A. Zeeb" To: hackers@freebsd.org Subject: Why I dislike MPASS... Message-ID: <57o4rnnq-013s-3nsn-59n5-4ssn1pq81s94@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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; format=flowed; charset=US-ASCII X-Spamd-Bar: - X-Spamd-Result: default: False [-1.83 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.47)[0.468]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; R_DKIM_NA(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zabbadoz.net]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4TzCj34fPkz4qSS Hi, needless to say, this needed a 2nd kernel, a reproducer (when no gdb and no crash dump was avail). XXX-BZ KABOOM 45000 > 0 && 45000 <= 360 && 45000 < 1536 panic: Assertion (key.to) > 0 && (key.to) <= w_max_used_index && (key.to) < witness_count failed at /usr/src/sys/kern/subr_witness.c:3118 This is why I dislike MPASS; if it hits you are often no wiser as to why, especially if people added more than a single condition. Why do we make our life harder ourselves by not having informative messages (I mean that is what the comment above MPASS claims)? I still have no idea how I get to that assertion but at least key.to looks dodgy enough so that I can go look where-as before I really didn't know if I had hit a limit or which one... /bz -- Bjoern A. Zeeb r15:7 From nobody Tue Mar 19 00:57:28 2024 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 4TzCxW4Dlcz5FN09 for ; Tue, 19 Mar 2024 00:57:35 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TzCxW3Mkrz4rf1; Tue, 19 Mar 2024 00:57:35 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710809855; 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=jQQwF3+CQglorcr88qrJYeo3BrfMNHu30qOFviLKgvA=; b=DBeMHoN1RHCUAmmVy9IMsKEx0l0hCXHmUX6EL6g+k0IiugkO5PflFMUydNeunp7iQmVbeR ugfVihrnbjwHHgfEdsN2Sl6rHP7SRVKxLatDRjHeo4OkFtoxhfbcVqhB3uh5gJH3TXqZr3 7qiUllZZQOzv7uH6A8adMX7gKuvrCGJMmVDDw9C65buJf6g8a7IQrZFLtWd5ipdpb/TlOB yE3UbZBXeEiHlxjTlTWsdf078PGqc45L3+I27dqDBNS4qnlGgvnjJGEAHiewAUsc3gQOF7 BYGnXYJkHmUPqVK5RrLC0kFR7e5cdoNzsgb0zR9B2J0YgoWEVtkvIK7r88/ISQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1710809855; a=rsa-sha256; cv=none; b=Z+AOen4ELrojWNYwtjmx6L4lHj+USrO13yAVeED6H/G5Tfjx8M9fmFN4wTnx7pqJ9eKfEK aQo8hUaxIOQnqCP8QmDeD2iIZRatEQnNsb2clwnrGtTMCzNSKewtSgWKQ8A1Bh1StQ7j1+ Qx4XgM2NcxulPG3McAXMhk1n+3wgyVNxlCnuccyfXNceMwetA1t5DgD6HQ4AfGHpYl1h+x D1Tr9KdI0YTgrWtL3fcf8RtgFq8An1MApqPu5jTJyz+b1hvLAlq8btlqYbwqiTalysHjdn b7f35h6ZEGcDRZQVfDYCoUoa25KguyAbAHkhgVOe2N9qFuWtWZT63auOfSMIVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710809855; 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=jQQwF3+CQglorcr88qrJYeo3BrfMNHu30qOFviLKgvA=; b=flF7Kj4JThBG1El21z+g7YFqzTYvqtUbz3PW6o3AucEcfFUVMbYIK8KFHUrasftyitHmX2 BtmZKpGJJk0Qq1loSaPAGYwkIVNdjhKTWF2Xz4y30ul75q1oBORfVQVH5tO4DAg9Q+2M4p bDgy1rZWaoTMvzl6+JO6/cefzOzPxixn7HD+PzvIWlFkIOl88SuNgs9gbcVSI2g40eeBgY Qwd1yFJUr4gYjsbP1uxybtcTSvtdcmO0mcM7uW7y0WX9lK6HJLHO4/hIeQQHFNhsIWVIUJ THQyQ+9bTLKqvgcVeGvGvKf402jiJKKS9TDvqYKqkatwjX0Erk6o5aYiKsN9Ig== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TzCxW2FCCzVHp; Tue, 19 Mar 2024 00:57:35 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 7B6834A8D5; Tue, 19 Mar 2024 01:57:32 +0100 (CET) From: Kristof Provost To: "Bjoern A. Zeeb" Cc: hackers@freebsd.org Subject: Re: Why I dislike MPASS... Date: Tue, 19 Mar 2024 08:57:28 +0800 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: <57o4rnnq-013s-3nsn-59n5-4ssn1pq81s94@yvfgf.mnoonqbm.arg> References: <57o4rnnq-013s-3nsn-59n5-4ssn1pq81s94@yvfgf.mnoonqbm.arg> 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: multipart/alternative; boundary="=_MailMate_FA3B4B96-0ECB-4EA5-937A-ECEE45C6FE33_=" Content-Transfer-Encoding: 8bit --=_MailMate_FA3B4B96-0ECB-4EA5-937A-ECEE45C6FE33_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 19 Mar 2024, at 8:46, Bjoern A. Zeeb wrote: > Hi, > > needless to say, this needed a 2nd kernel, a reproducer (when no gdb > and > no crash dump was avail). > > XXX-BZ KABOOM 45000 > 0 && 45000 <= 360 && 45000 < 1536 > panic: Assertion (key.to) > 0 && (key.to) <= w_max_used_index && > (key.to) < witness_count failed at > /usr/src/sys/kern/subr_witness.c:3118 > > This is why I dislike MPASS; if it hits you are often no wiser as to > why, especially if people added more than a single condition. > > Why do we make our life harder ourselves by not having informative > messages (I mean that is what the comment above MPASS claims)? > > I still have no idea how I get to that assertion but at least key.to > looks dodgy enough so that I can go look where-as before I really > didn't > know if I had hit a limit or which one... > Presumably you’d prefer something that’d log the actual compared values? E.g. something like `ASSERT_GT(key.to, 0); ASSERT_LTE(key.to, w_max_used_index); ASSERT_LT(key.to, witness_count);`? I vaguely recall seeing discussion of similar constructs in the ZFS code. I’d enthusiastically support adding, and encouraging the use of, macros like that. I’d object to removing or discouraging MPASS(), because I fear that will reduce the number of assertions developers add to the code, and we’d be objectively worse off in a world where the assertion was ` ` rather than `MPASS((key.to) > 0 && (key.to) <= w_max_used_index && (key.to) < witness_count);`. We should probably encourage people to avoid complex expressions in MPASS(), but I’d still much rather have the complex expression than nothing at all. Best regards, Kristof --=_MailMate_FA3B4B96-0ECB-4EA5-937A-ECEE45C6FE33_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 19 Mar 2024, at 8:46, Bjoern A. Zeeb wrote:

Hi,

needless to say, this needed a 2nd kernel, a reproducer (= when no gdb and
no crash dump was avail).

XXX-BZ KABOOM 45000 > 0 && 45000 <=3D 360 &= amp;& 45000 < 1536
panic: Assertion (key.to) > 0 && (key.to) <=3D w_max_used_i= ndex && (key.to) < witness_count failed at /usr/src/sys/kern/s= ubr_witness.c:3118

This is why I dislike MPASS; if it hits you are often no = wiser as to
why, especially if people added more than a single condition.

Why do we make our life harder ourselves by not having in= formative
messages (I mean that is what the comment above MPASS claims)?

I still have no idea how I get to that assertion but at l= east key.to
looks dodgy enough so that I can go look where-as before I really didn't
know if I had hit a limit or which one...


Presumably you=E2=80=99d prefer something that=E2=80=99d = log the actual compared values?
E.g. something like ASSERT_GT(key.to, 0); ASSERT_LTE(key.to, w_max_used_index); ASSE= RT_LT(key.to, witness_count);?
I vaguely recall seeing discussion of similar constructs in the ZFS code.=

I=E2=80=99d enthusiastically support adding, and encourag= ing the use of, macros like that.

I=E2=80=99d object to removing or discouraging MPASS(), b= ecause I fear that will reduce the number of assertions developers add to= the code, and we=E2=80=99d be objectively worse off in a world where the= assertion was rather than MPASS((key.to) > 0 && (key.to) <=3D w_max_use= d_index && (key.to) < witness_count);.

We should probably encourage people to avoid complex expr= essions in MPASS(), but I=E2=80=99d still much rather have the complex ex= pression than nothing at all.

Best regards,
Kristof

--=_MailMate_FA3B4B96-0ECB-4EA5-937A-ECEE45C6FE33_=-- From nobody Tue Mar 19 12:19:11 2024 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 4TzW433mJWz5FDD4 for ; Tue, 19 Mar 2024 12:19:15 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TzW4234JMz4q5K for ; Tue, 19 Mar 2024 12:19:14 +0000 (UTC) (envelope-from jrm@ftfl.ca) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of jrm@ftfl.ca designates 209.85.219.46 as permitted sender) smtp.mailfrom=jrm@ftfl.ca Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-6928a5e2479so15684776d6.0 for ; Tue, 19 Mar 2024 05:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710850753; x=1711455553; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IG5bq2VfJPvrvHV5h3K2XRlTF5/+qYSWADjhosp4NiE=; b=EaukFRxnaWC5dM1B3uiOAEJF8j+1okxlWrvxR+jFthU/kPWVwzKLGT4mjwsXi7CLiH Z035z0uQerwQli9201THlHxeOf/Mmw4e1EzTJaPTbKBB2bL6MPaciw1iMKejNRpZQpog OMLzkKllOHToQhS8LD6x/H4Nb5Kd5/57dfCOwz3anybUIrVbstJZMuCfiTU+bEKztFpZ KSZeKoLU7rmufzI+zRXgNH6CqIyqeuxxDKpGjAIu09sxCFTDk5gG1Ic+TV/tUQxJ570l R0NEfmjc4nQI5j1saCcdGaHa5te1lFRVrIklPuxxFHD9pyhZ2e58CKtuPEbkosJ2SPFV O/eQ== X-Gm-Message-State: AOJu0YxAEgiF7/Z4zkoJrfpY8iELKJmcGA30AAyxGd2bLeWe58EFphy5 UnNCgganbUkrplNSbTSHaYavZ7SJfCyfCIpdsh88dszjZaXmh3kOKbgDzD0A1y9LMbVNBmbJ96Q = X-Google-Smtp-Source: AGHT+IENbSNLOGzyK7pJuyhcT+5tJnGboqoJm44Gz1r8w5p7xYrEUjZ53tQyCd5MBWrVWvjxKAN6lw== X-Received: by 2002:ad4:5bef:0:b0:691:641a:7bb9 with SMTP id k15-20020ad45bef000000b00691641a7bb9mr19401408qvc.43.1710850752643; Tue, 19 Mar 2024 05:19:12 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-250-113.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.250.113]) by smtp.gmail.com with ESMTPSA id r7-20020ad45767000000b00690f9ea30aesm6329250qvx.26.2024.03.19.05.19.11 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Mar 2024 05:19:11 -0700 (PDT) From: Joseph Mingrone To: Karim Taha Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: [GSOC 2024] Unified kernel tracing interface In-Reply-To: <86v85qxo2z.fsf@phe.ftfl.ca> (Joseph Mingrone's message of "Wed, 13 Mar 2024 10:23:32 -0300") References: <86v85qxo2z.fsf@phe.ftfl.ca> Date: Tue, 19 Mar 2024 09:19:11 -0300 Message-ID: <86plvq5s8w.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 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 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.71 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.81)[-0.809]; FORGED_SENDER(0.30)[jrm@FreeBSD.org,jrm@ftfl.ca]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[jrm]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[jrm@FreeBSD.org,jrm@ftfl.ca]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.46:from]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.46:from] X-Rspamd-Queue-Id: 4TzW4234JMz4q5K On Wed, 2024-03-13 at 10:23, Joseph Mingrone wrote: > On Wed, 2024-03-13 at 13:58, Karim Taha wrote: >> Hi, >> I'm a computer engineering fresh grad. I'm interested in working on the >> `Unified kernel tracing interface` project, however, the `ideas` page does >> not list a mentor for direct contact and inquiries. >> I was accepted in the GSOC2023 QEMU program, it was on FreeBSD, so I used >> FreeBSD for around six months, I can use it with no issue. >> I would like to know what level of kernel programming experience is >> expected, and if the project could be tackled in a VM? >> -- >> Karim > Hi Karim, > The person who proposed the project and was originally going to be the > mentor is no longer available. I'll investigate whether we can find > another mentor and reply within a few days. > Regards, > Joe Hello again Karim, I exchanged a few more emails with people associated with this project. Unfortunately, we haven't been able to secure a qualified mentor, so you should consider selecting a different project. Do any of the others on https://wiki.freebsd.org/SummerOfCodeIdeas look interesting to you? Please let me know if you need help evaluating any of the other projects. Regards, Joe From nobody Tue Mar 19 13:43:04 2024 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 4TzXx06jXHz5FMkv for ; Tue, 19 Mar 2024 13:43:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TzXwz6ScBz43QR for ; Tue, 19 Mar 2024 13:43:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A2E6C8D4A217 for ; Tue, 19 Mar 2024 13:43:06 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 520472D029D8 for ; Tue, 19 Mar 2024 13:43:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id rR2aYDcQ8q2H for ; Tue, 19 Mar 2024 13:43:05 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 03CC52D029D2 for ; Tue, 19 Mar 2024 13:43:04 +0000 (UTC) Date: Tue, 19 Mar 2024 13:43:04 +0000 (UTC) From: "Bjoern A. Zeeb" To: hackers@freebsd.org Subject: Re: Why I dislike MPASS... In-Reply-To: Message-ID: <261pq217-nqq5-9snn-r407-oo895s6843ss@yvfgf.mnoonqbm.arg> References: <57o4rnnq-013s-3nsn-59n5-4ssn1pq81s94@yvfgf.mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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: multipart/mixed; boundary="1098556516-1809024439-1710855785=:3455" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.03 / 15.00]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.73)[-0.728]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; DMARC_NA(0.00)[zabbadoz.net]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4TzXwz6ScBz43QR This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-1809024439-1710855785=:3455 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 19 Mar 2024, Kristof Provost wrote: > On 19 Mar 2024, at 8:46, Bjoern A. Zeeb wrote: >> Hi, >> >> needless to say, this needed a 2nd kernel, a reproducer (when no gdb and >> no crash dump was avail). >> >> XXX-BZ KABOOM 45000 > 0 && 45000 <= 360 && 45000 < 1536 >> panic: Assertion (key.to) > 0 && (key.to) <= w_max_used_index && (key.to) < >> witness_count failed at /usr/src/sys/kern/subr_witness.c:3118 >> >> This is why I dislike MPASS; if it hits you are often no wiser as to >> why, especially if people added more than a single condition. >> >> Why do we make our life harder ourselves by not having informative >> messages (I mean that is what the comment above MPASS claims)? >> >> I still have no idea how I get to that assertion but at least key.to >> looks dodgy enough so that I can go look where-as before I really didn't >> know if I had hit a limit or which one... >> > Presumably you’d prefer something that’d log the actual compared values? Yes, because without them you still don't know what's wrong. > E.g. something like `ASSERT_GT(key.to, 0); ASSERT_LTE(key.to, > w_max_used_index); ASSERT_LT(key.to, witness_count);`? > I vaguely recall seeing discussion of similar constructs in the ZFS code. > > I’d enthusiastically support adding, and encouraging the use of, macros like > that. > > I’d object to removing or discouraging MPASS(), because I fear that will > reduce the number of assertions developers add to the code, and we’d be > objectively worse off in a world where the assertion was ` ` rather than > `MPASS((key.to) > 0 && (key.to) <= w_max_used_index && (key.to) < > witness_count);`. > > We should probably encourage people to avoid complex expressions in MPASS(), > but I’d still much rather have the complex expression than nothing at all. Yes, MPASS should probably only be used for a single simple expression the most. And I am all for assertions as they are great documentation of assumption in code as well. It's the first stage of writing test code as well ;-) But using KASSERT with a proper message which isn't a teapot is too hard and too time consuming? Always think of when you get a PR from a user (not a machine you sit in front of) what can you do with this information and what's the first things you'd love to know. I often find that the latter changes as code changes or one has a better understanding of a problem (depending on the complexity of the problem). But I also always find that if I didn't have the initial extra information I would have to ask for it often by guessing the best three things... or if ddb is avail at least can have something looked up "type show ifnet and send that output along". /bz -- Bjoern A. Zeeb r15:7 --1098556516-1809024439-1710855785=:3455-- From nobody Tue Mar 19 17:51:15 2024 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 4TzfR90hTqz5F0x3 for ; Tue, 19 Mar 2024 17:51:17 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TzfR86l4kz4dtd; Tue, 19 Mar 2024 17:51:16 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710870676; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=fo/WqqxK2IpWlDLDR1LtdJSXC4evbG8W6uajwJ8Z4xY=; b=d8VqRQ4VpgDl7snftZMJiHG9qAZiklTxwx2AoM9saoPwZzCZgS5unhN4oYgLDnR20IPOlF y9/E120LF0qzmJz4CpIpCrS+1Yq0WHeo6nUCId6ls1+pKmD5otwHumAqznff6VX/68fP7K cofIA2XSpeHB5Bfnd4CeFMvnNFTKQVWuhbjDAOb8RDPwPNyL2lC5pvbPIpyeo322Abp6Ck VY2CyljatuMoyoX48SmTq149gA0CSMtO9D7zgdqPpJoFsgy7YaAG6k+si3wFdRCdWfgGcN eBRFJHlmzzXMYQBH8vRypbrlHVrNj3H2P9d20kcsGyZ16FJjeLi8A8xqbfv44g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1710870676; a=rsa-sha256; cv=none; b=gwrlSlrF59rEElQEd+jdapz/8+Jdg8/seOidc3gAh1y9Dw5mLsUyITbqCcdtKoPGfbWqLV lLRPEmgnF7ZBodwMEtxBscFCLDYijgc7DGqFznYisk1X5/07Mfz6kl/xDNmXYboQfPaEpv u4JV4QfsT2H7Bk/MZjClcP1UpULxJWLZRlboFsQPsZ8ADN/YZAtxEhs8CqHAYmqcl64dao RqX6eIw6+/SZnBmEK2t0dhmPjgtwgrMBHLzssIZbC9vu3Kq9zeWJK0cGf0sQF73rGzRnaE Zg36gYAbxESSp1sBC1riWh8QARvLqjoeX9gRwbzuCTqvjb07w+9zw5LboScVRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710870676; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=fo/WqqxK2IpWlDLDR1LtdJSXC4evbG8W6uajwJ8Z4xY=; b=A4HaRhxCN1jIBt8K+wEMTguI2UpzZm/92vigFCCiqwh4miSKvH/A8CQEIT7o1hXgJejVuA wXgTncUHd7YfcVnIVUmbdAAj4TWNtCPyzx5/DicU4aSM4MptXUrM+hjkopMokc/3Fhn8Vg n3FxT1birZX+FhvsEsTn9jfOjX3X17ox/1zY/yXNXGvNjFSHbKsC3irK+hn6pUC1R5EqV1 C7qxwrdbB0PFmQDY/rU4Vh1lttTyAua5yGMm9rS0EitcJuscxTmTt3JrsJI2CvaJ57VycQ AfTjaN2w78HxaYSv9CKc+K1p4L1GfUzKNIeIgtZoHeMoHh9cF8gGE/BjU4fb9g== Received: from [192.168.1.151] (host-173-212-76-127.public.eastlink.ca [173.212.76.127]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TzfR8587Sz16fy; Tue, 19 Mar 2024 17:51:16 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: Date: Tue, 19 Mar 2024 14:51:15 -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 Thunderbird Subject: Re: Why I dislike MPASS... Content-Language: en-CA To: "Bjoern A. Zeeb" , hackers@freebsd.org References: <57o4rnnq-013s-3nsn-59n5-4ssn1pq81s94@yvfgf.mnoonqbm.arg> <261pq217-nqq5-9snn-r407-oo895s6843ss@yvfgf.mnoonqbm.arg> From: Mitchell Horne Autocrypt: addr=mhorne@freebsd.org; keydata= xsBNBFyS2dQBCADdiXBG8hBVLmYbxu7aSzbwLwUf3HkGFz3rooS1kwyy+SfmjZ4UKNnl9WMx WKrJ7OAZpiNH6bLQ5nsqfx09OnpWL8c/QuPbhNdUywQoqqYpRI0K8GEn//nS9Gs0KTYwVpWb XlrzP+jf3Uh/9L5mcQmStLIH4zaaqMYHW+pMuPrvBmLIHTvLj2QjOkxslrcUdord9uvxe5Ht LU8RuTpQpHOKz705Z9/v7twFdi2HtKzpLwO6SzVyu351di1J+GihsVpcT5josQV5cHbIP3Un x+kmtKBEEc/jl/zBglF7ruWUtwgbryID+2ZPEaO1Mj+RResX4LFVMusq3uUpWRb5WJXxABEB AAHNI01pdGNoZWxsIEhvcm5lIDxtaG9ybmVARnJlZUJTRC5vcmc+wsCUBBMBCgA+AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEkp/cYPcfabAiQvACi/gnTOdUid8FAmIyDpUFCQtC z0EACgkQi/gnTOdUid8IsQf+N8IptrrCgifT5Z0/WUVFfnHThFOKf4zBjaGswsIM8+VKsKnF 15jCWHODUHP6s+dcQ4nQi81PHPsnMfBSkGPvN/X3ess2/1KUVkH+6tAJbqXDjXhD8HT+i0NM QEFIXlLnotpgIKW3yOHjKv3ZvKw9LCvUjyNY9vOJmLk/6AbbkFh+INo65nXtQWb/hM5FVEHW S+zUoU8AqZRJoVAQfj9wmIfg/HdsxeDGKL0zkv5AwKpccvb8VJNGJbCVMgoy5uQYcUeXxcie cg0VlbFLshNQTfyhVQ85vyuHahARrUWs/k8KiYODoBnW1ChtyF8yM6VZTzSYx7pINqPq2YZy i/Htd87ATQRcktnUAQgA3zt4M4ecoQqfxpjliNLujt9klDqvmkJvWmzMuMXdzlPgGRJ0doio 9YIeEdkOt6xN0pPTK/ReCZ8WqFQ8zo23u1pwGuo0CnR58XF19wyxyUuKu/PHbt+56mC8tNHm AXsMyXQmlDqWvn/WzLY7euNRtNS4QQIwtxfM5EC4GGa5KQwxn0kM7dkUSOE/cxr+/kNbHHzb gagZR4cnNUqtPPr3dYXcibCTzgz96Lyt3/qMLXX9RTBRzu+O6E+byxWOe8ar/ZlwY2b4wTQG mhgNttkSxKtxMpZnd8+DGV/bI1P5Ct/K2GeCwNyupQGON5ymn6o7jTch+qmFX0ItkBWO4zn4 9QARAQABwsB8BBgBCgAmAhsMFiEEkp/cYPcfabAiQvACi/gnTOdUid8FAmIyDtwFCQtCz4gA CgkQi/gnTOdUid/i5gf/aQ75pJR4TJFM2vVVr6PDIwTdl0b5EchB4w4s4g/zE84XNbMOQanb BginLYEhAacLQVAvM3XdvUEhwrhaMQdjdSEB1krResL3/mbxrtKwdHSMbHA3IS3XdvxFWTB7 P5JjUSPsW6hqgoidbn4w3OxaNHhs45H2b0Nx5QiKcSyepmCZuB52gCEHnEnrdaz8TFQMXOLq 94WbTmZeIjChW3FB61m1gTf0UEFjoZAfTAUB+pbwoCa4AykIeZnDC19vjsruVU9Gy5rLglwd bjsZNfXIJGOZNEvdF8FOBwM7DlXx7SYvTJcUNoNJjOKtQ0bYGVgGqYOB/y2mTjVuKeU0eOkN Uw== In-Reply-To: <261pq217-nqq5-9snn-r407-oo895s6843ss@yvfgf.mnoonqbm.arg> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/19/24 10:43, Bjoern A. Zeeb wrote: > On Tue, 19 Mar 2024, Kristof Provost wrote: > >> On 19 Mar 2024, at 8:46, Bjoern A. Zeeb wrote: >>> Hi, >>> >>> needless to say, this needed a 2nd kernel, a reproducer (when no gdb and >>> no crash dump was avail). >>> >>> XXX-BZ KABOOM 45000 > 0 && 45000 <= 360 && 45000 < 1536 >>> panic: Assertion (key.to) > 0 && (key.to) <= w_max_used_index && >>> (key.to) < witness_count failed at /usr/src/sys/kern/subr_witness.c:3118 >>> >>> This is why I dislike MPASS; if it hits you are often no wiser as to >>> why, especially if people added more than a single condition. >>> >>> Why do we make our life harder ourselves by not having informative >>> messages (I mean that is what the comment above MPASS claims)? >>> >>> I still have no idea how I get to that assertion but at least key.to >>> looks dodgy enough so that I can go look where-as before I really didn't >>> know if I had hit a limit or which one... >>> >> Presumably you’d prefer something that’d log the actual compared values? > > Yes, because without them you still don't know what's wrong. > > >> E.g. something like `ASSERT_GT(key.to, 0); ASSERT_LTE(key.to, >> w_max_used_index); ASSERT_LT(key.to, witness_count);`? >> I vaguely recall seeing discussion of similar constructs in the ZFS code. >> >> I’d enthusiastically support adding, and encouraging the use of, >> macros like that. >> >> I’d object to removing or discouraging MPASS(), because I fear that >> will reduce the number of assertions developers add to the code, and >> we’d be objectively worse off in a world where the assertion was ` ` >> rather than `MPASS((key.to) > 0 && (key.to) <= w_max_used_index && >> (key.to) < witness_count);`. >> >> We should probably encourage people to avoid complex expressions in >> MPASS(), but I’d still much rather have the complex expression than >> nothing at all. > > Yes, MPASS should probably only be used for a single simple expression > the most. > > And I am all for assertions as they are great documentation of assumption > in code as well.  It's the first stage of writing test code as well ;-) > > But using KASSERT with a proper message which isn't a teapot is too hard > and > too time consuming? > > Always think of when you get a PR from a user (not a machine you sit in > front of) what can you do with this information and what's the first > things you'd love to know. > > I often find that the latter changes as code changes or one has a > better understanding of a problem (depending on the complexity of the > problem).  But I also always find that if I didn't have the initial > extra information I would have to ask for it often by guessing the best > three things...  or if ddb is avail at least can have something looked > up  "type show ifnet and send that output along". > > /bz > > Hi, I am in total agreement about the limitations of certain assertion messages. In order to begin to understand _why_ an assertion failed, there can be no ambiguity in _how_ it failed. I won't fight for deprecating MPASS, but the small action we can take today is to improve the documentation of these macros, for those who might read it. Here's an attempt at some guidelines and examples: https://reviews.freebsd.org/D44434 Suggested improvements are welcome, fully formed text preferred. Cheers, Mitchell From nobody Thu Mar 21 02:59:21 2024 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 4V0VYH08gvz5FcLp for ; Thu, 21 Mar 2024 02:59:31 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V0VYG6sSLz4GSk; Thu, 21 Mar 2024 02:59:30 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710989970; 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=aGT3H/lfq77F/WFc73hFgYSg77PzsCg4a0pAyckQssY=; b=qGFd3sdEvNGadpPEvspCWlBLOrp4lZaRztqGQLb0J/vMhKqlskizJTA9Qt41s20KSZDNC8 DKG/4++0NOL5jGf9hiqfcgDNPVaF2KteTrs2YQxHOpXoB28VXhFQynS2CfeDORoehNZ1ii nBKcVBkb2Pj6vBAcS9n/7jQDOU6en/olfFR+xswnUvRPk246WtHtR1SXnXsIDQLR4dadkn eWvGb0tmLvV8FWpYYHz8eV/03h02YFKtCZKPcFnIihHAiXwPLCOi6zMx6b9Icl9RuYOrkX XP8MkG/r3HAc+1/f0z7FAFGKt21JEq2rt7jDqXD+ju4/ze3DpEg3/00Zpp/sPQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1710989970; a=rsa-sha256; cv=none; b=JlyC9SOUEc6OxGFdPnj/KIUBKLPpVjZmh6tXXAXaLsFxz5ByoTLiT3a+BYTZ+6cPXb0tDL g2OT7jL4aTulr4oJMikBPsRjxgT//5RaWBrdvfrEglsFn9wEPgNHg4FW1kYyaqJsQ5lcU7 9GsitGFYWu+HaGiaQgz7hUWlbF6nzcz7jLagZooepPo39VjBJ5txPHaGYCmtf9tRIQJHLj bsDyZMV42m/TlAebRLotrlLHFZ2/FJKng2CtrZv6gR4bJShf+cFPQKUeJNemU7oLY0xr8+ kJ5C7XNs2HbUPhex0E2Rb1oNEMM3yIrO3ocijcEGDLVWvXryl5lZ+2DsBKD7ag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710989970; 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=aGT3H/lfq77F/WFc73hFgYSg77PzsCg4a0pAyckQssY=; b=vIMMzDpMYXHdBYoleXCFVAgGISJI5dNyLarmJnVQSDTCghhbem4aR3c3M4PVnyMYZ93j5Z z+8IZdMamWC2dt7ZLBMohELnkRkh5/cFOh40UY1XHmnfcvndB+M51xahDtPdT5fnnfQQfj 3SAPi7OvgrWNYTHsMtQdDVQE75UFDWpNOPg3dOpyvSr5MEDIbfxQx5sDrFhYX4j70RnHSr nlfW0JEqubGSN7a5MNDnUr2zaPSJpQRMPE9MIm4N/fNPDzxxRcFC8PwyY4DOaB7/aQD5Xi Czw1v1rQ3osymzdHx5BuoDIMQ2ugL6e3qhDaXmH+nAEc5WHEK8NXsvlGzHmSKA== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4V0VYG4XczzXsV; Thu, 21 Mar 2024 02:59:30 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 5A96E4F8C6; Thu, 21 Mar 2024 03:59:27 +0100 (CET) From: Kristof Provost To: Igor Ostapenko Cc: freebsd-hackers@freebsd.org Subject: Re: Add jail execution environment support to the FreeBSD test suite Date: Thu, 21 Mar 2024 10:59:21 +0800 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: References: <2bjQNp1msrv-_AqyamMun6kY-SCqbgPm3Q7DqVQHAYlqvFkiE1i85svfIT-QQdUG1cg3cKippyTyv8Z-5nbLu4WaMutgZQ7KT-YYo_5Pbro=@pm.me> 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: multipart/alternative; boundary="=_MailMate_F71C8465-E854-4AF9-9342-2B9110ED52D5_=" Content-Transfer-Encoding: 8bit --=_MailMate_F71C8465-E854-4AF9-9342-2B9110ED52D5_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I’ve been toying with this patch. Adding only the following patch I can get Kyua to run the pf tests in parallel: diff --git a/tests/sys/netpfil/pf/Makefile b/tests/sys/netpfil/pf/Makefile index 867b98e5f6c2..c2f0f15fa798 100644 --- a/tests/sys/netpfil/pf/Makefile +++ b/tests/sys/netpfil/pf/Makefile @@ -51,8 +51,8 @@ ATF_TESTS_PYTEST+= frag6.py ATF_TESTS_PYTEST+= nat66.py ATF_TESTS_PYTEST+= sctp.py -# Tests reuse jail names and so cannot run in parallel. -TEST_METADATA+= is_exclusive=true +TEST_METADATA+= execenv="jail" +TEST_METADATA+= execenv_jail="vnet allow.raw_sockets" PROGS= divapp That gets the test time, with parallelism=5, down from 22 minutes to 5m40s. So I’m rather keen to see this work land. My read from the reactions here is that people are generally okay with the approach, especially (I assume) given that the current version lets us turn this on on a per-test basis. Is there anything else anyone wants to raise before we land this? Best regards, Kristof On 28 Feb 2024, at 2:32, Igor Ostapenko wrote: > Hi, > > The patch was updated after the recent discussion. > > Currently, the patch provides the following new functionality, from > bottom to > top: > > 1 ATF based tests > > - The new "execenv" metadata property can be set to explicitly ask for > an > execution environment: "host" or "jail". If it's not defined, as all > existing tests do, then it implicitly means "host". > > - The new "execenv.jail" metadata property can be optionally defined > to ask > Kyua to use specific jail(8) parameters during creation of a > temporary > jail. An example is "vnet allow.raw_sockets". > > > 2 Kyuafile > > - The same new metadata properties can be defined on Kyuafile level: > "execenv" and "execenv_jail". > > - Note that historically ATF uses dotted style of metadata naming, > while > Kyua uses underscore style. Hence "execenv.jail" vs. "execenv_jail". > > > 3 kyua.conf, kyua CLI > > - The new "execenv" engine configuration variable can be set to a list > of > execution environments to run only tests designed for. Tests of not > listed > environments are skipped. > > - By default, this variable lists all execution environments supported > by a > Kyua binary, e.g. execenv="host jail". > > - This variable can be changed via "kyua.conf" or via kyua CLI's "-v" > parameter. For example, "kyua -v execenv=host test" will run only > host-based tests and skip jail-based ones. > > - Current value of this variable can be examined with "kyua config". > > > The patch is https://reviews.freebsd.org/D42350. > > Any help with review and testing is welcome. Its test plan covers the > details and refers to the demo patch of how existing tests could be > converted to be run in a jail. > > > Best regards, Igor. > > > On Thursday, February 22nd, 2024 at 10:57 PM, igor.ostapenko@pm.me > wrote: >> >> >> Hi FreeBSD developers, >> >> There is a proposal to improve the FreeBSD test suite. >> >> >> 1 The Problem >> >> The FreeBSD test suite is based on the Kyua framework. The latter >> supports >> running tests in parallel. However, some tests cannot be run in >> parallel and >> are marked with is_exclusive="true" metadata, which makes Kyua run >> such tests >> in sequence. >> >> Many tests are not meant to be exclusive conceptually, they are so >> for very >> simple technical reasons. For instance, some network related tests >> are based >> on jail and vnet usage. It's convenient for such tests and it >> provides a lot >> of isolation already not to conflict with other tests. But they are >> still >> marked as exclusive due to the shared space of jail names, routing, >> etc. >> >> The project seeks more tests, and it's kind of a trend for new tests >> like >> jail/vnet based ones to be created as is_exclusive="true" from the >> very >> beginning. It only piles up the suite with exclusive tests, e.g. new >> tests >> from my side faced a fair question from a reviewer whether they could >> be >> re-designed for a parallel run. [1] >> >> If such tests were 100% isolated they would be able to run in >> parallel and >> decrease the test time for CI runs and for the runs within the >> development >> process. >> >> And the problem is that trying to add more isolation by a test itself >> looks to >> be a doable task from a glance, but it would add a lot of complexity >> to a test >> code, or could be found as an impossible task in a specific case. >> >> >> 2 The Idea >> >> The idea is not new. A test could be running in a jail -- it provides >> the >> required isolation with minimum or zero effort from a test. >> >> >> 3 The Implementation >> >> There is a lot of work done already and the working patch passed the >> initial >> review (thanks to markj@ and ngie@). [2] >> >> It adds a new concept to the Kyua framework -- an execution >> environment. Two >> new metadata were added for that: execenv and execenv_jail. >> >> execenv is a switch to select an environment. If a test's metadata >> defines >> execenv="jail" then Kyua will create a temporary jail, run such test >> within >> it, and remove the jail. If execenv="host" is provided or execenv >> metadata is >> undefined then Kyua will run such test as it does today. >> >> execenv_jail metadata takes effect only in case of execenv="jail". It >> allows a >> test to request specific parameters for its jail. These parameters >> are simply >> arguments to jail(8), e.g. execenv_jail="vnet allow.raw_sockets". >> >> >> 4 The Adoption >> >> ATF based tests can easily define this new metadata via Kyuafile or >> directly, >> e.g. for atf-sh based tests: >> >> test_head() >> { >> atf_set descr "Test foo in case of bar" >> atf_set require.user root >> atf_set execenv jail >> atf_set execenv.jail vnet allow.raw_sockets >> } >> >> Non-ATF based ones will do it via Kyuafile. Our test suite does it >> through a >> Makefile: >> >> TEST_METADATA+= execenv="jail" >> TEST_METADATA+= execenv_jail="vnet allow.raw_sockets" >> >> The patch got some little evolution, I started with a single >> execenv_jail >> metadata, and during the patch discussion and review, I ended up with >> two >> knobs: execenv and execenv_jail. It turned out to be a cleaner and >> less tricky >> interface such way. The evolution reasoning can be found in the >> history of the >> respective Differential. [2] >> >> >> 5 MFC Concerns >> >> For now, I see at least one issue from the usual project workflow >> perspective. >> Let's imagine that the Kyua framework got this execenv feature >> committed to >> 15-CURRENT, we started to convert existing tests and create new ones >> to use >> execenv="jail". If some feature or a bug fix needs to be ported back >> to >> 14-STABLE or 13-STABLE, then "old" Kyua without execenv feature will >> fail to >> run such tests: >> >> kyua: E: Load of 'Kyuafile' failed: Failed to load Lua file >> 'Kyuafile': Kyuafile:9: Unknown metadata property execenv. >> >> From a combinatorics perspective, the first three options pop up to >> deal with >> that: >> a) Patch Kyua the same way for the supported STABLE branches so it >> will be >> able to run back ported tests based on execenv="jail" (it's not >> system ABI >> change after all) >> b) Exclusively patch Kyua framework for the supported STABLE branches >> to >> simply skip such tests (does not look to provide much benefit) >> c) Do not back port tests, only the fix/feature itself (kind of a bad >> idea) >> >> >> 6 The Demo >> >> My test environment showed promising run time numbers for almost the >> whole >> test suite (ZFS excluded). One of the tests yielded 36 min with test >> parallelism improvement versus 1 h 25 min without. In my case with 8 >> cores, >> the suite runs about 2 times faster with the improvement. [3] >> >> >> 7 Action Points >> >> My current vision of the plan looks as follows: >> - [ ] community: Review, testing, comments -- probably we want to >> change the >> design >> - [ ] committers: Help with the main commit -- it should hit >> freebsd/kyua >> GitHub fork first [4], then vendor branch, and merge to >> main after >> - [ ] igoro: Provide the subsequent PRs to separate FreeBSD specifics >> and fix >> existing Kyua tests >> - [ ] igoro: Provide the PRs to add brand new tests of Kyua itself to >> cover >> the new feature >> - [ ] igoro: Provide the respective documentation updates >> - [ ] igoro: Migrate some of the existing tests for the start, e.g. >> netpfil/pf >> - [ ] committers: Help with review and respective commits/merges >> >> The plan is not strict, it depends on the discussion and interest of >> volunteers. >> >> I hope that this proposal is found valuable for the project. If so, >> any help >> is appreciated. >> >> >> [1] New tests exclusivity concern: https://reviews.freebsd.org/D42314 >> [2] The Kyua patch: https://reviews.freebsd.org/D42350 >> [3] The whole test suite demo: https://reviews.freebsd.org/D42410 >> [4] The respective PR to the fork: >> https://github.com/freebsd/kyua/pull/224 >> >> >> Best regards, Igor. --=_MailMate_F71C8465-E854-4AF9-9342-2B9110ED52D5_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

<Picking this mail to resurrect the thread>

I=E2=80=99ve been toying with this patch. Adding only the= following patch I can get Kyua to run the pf tests in parallel:

di=
ff --git a/tests/sys/netpfil/pf/Makefile b/tests/sys/netpfil/pf/Makefile
index 867b98e5f6c2..c2f0f15fa798 100644
--- a/tests/sys/netpfil/pf/Makefile
+++ b/tests/sys/netpfil/pf/Makefile
@@ -51,8 +51,8 @@ ATF_TESTS_PYTEST+=3D    frag6.py
 ATF_TESTS_PYTEST+=3D     nat66.py
 ATF_TESTS_PYTEST+=3D     sctp.py

-# Tests reuse jail names and so cannot run in parallel.
-TEST_METADATA+=3D        is_exclusive=3Dtrue
+TEST_METADATA+=3D execenv=3D"jail"
+TEST_METADATA+=3D execenv_jail=3D"vnet allow.raw_sockets"

 PROGS=3D divapp

That gets the test time, with parallelism=3D5, down from = 22 minutes to 5m40s.
So I=E2=80=99m rather keen to see this work land.

My read from the reactions here is that people are genera= lly okay with the approach, especially (I assume) given that the current = version lets us turn this on on a per-test basis.

Is there anything else anyone wants to raise before we la= nd this?

Best regards,
Kristof

On 28 Feb 2024, at 2:32, Igor Ostapenko wrote:

Hi,

The patch was updated after the recent discussion.

Currently, the patch provides the following new functiona= lity, from bottom to
top:

1 ATF based tests

- The new "execenv" metadata property can be set to expli= citly ask for an
execution environment: "host" or "jail". If it's not defined, as all
existing tests do, then it implicitly means "host".

- The new "execenv.jail" metadata property can be optiona= lly defined to ask
Kyua to use specific jail(8) parameters during creation of a temporary
jail. An example is "vnet allow.raw_sockets".

2 Kyuafile

- The same new metadata properties can be defined on Kyua= file level:
"execenv" and "execenv_jail".

- Note that historically ATF uses dotted style of metadat= a naming, while
Kyua uses underscore style. Hence "execenv.jail" vs. "execenv_jail".

3 kyua.conf, kyua CLI

- The new "execenv" engine configuration variable can be = set to a list of
execution environments to run only tests designed for. Tests of not lis= ted
environments are skipped.

- By default, this variable lists all execution environme= nts supported by a
Kyua binary, e.g. execenv=3D"host jail".

- This variable can be changed via "kyua.conf" or via kyu= a CLI's "-v"
parameter. For example, "kyua -v execenv=3Dhost test" will run only
host-based tests and skip jail-based ones.

- Current value of this variable can be examined with "ky= ua config".

The patch is https://reviews.freebsd.org/D42350.

Any help with review and testing is welcome. Its test pla= n covers the
details and refers to the demo patch of how existing tests could be
converted to be run in a jail.

Best regards, Igor.

On Thursday, February 22nd, 2024 at 10:57 PM, igor.ostape= nko@pm.me <igor.ostapenko@pm.me> wrote:

Hi FreeBSD developers,

There is a proposal to improve the FreeBSD test suite.

1 The Problem

The FreeBSD test suite is based on the Kyua framework. Th= e latter supports
running tests in parallel. However, some tests cannot be run in parallel = and
are marked with is_exclusive=3D"true" metadata, which makes Kyua run such= tests
in sequence.

Many tests are not meant to be exclusive conceptually, th= ey are so for very
simple technical reasons. For instance, some network related tests are ba= sed
on jail and vnet usage. It's convenient for such tests and it provides a = lot
of isolation already not to conflict with other tests. But they are still=
marked as exclusive due to the shared space of jail names, routing, etc.<= /p>

The project seeks more tests, and it's kind of a trend fo= r new tests like
jail/vnet based ones to be created as is_exclusive=3D"true" from the very=
beginning. It only piles up the suite with exclusive tests, e.g. new test= s
from my side faced a fair question from a reviewer whether they could be
re-designed for a parallel run. [1]

If such tests were 100% isolated they would be able to ru= n in parallel and
decrease the test time for CI runs and for the runs within the developmen= t
process.

And the problem is that trying to add more isolation by a= test itself looks to
be a doable task from a glance, but it would add a lot of complexity to a= test
code, or could be found as an impossible task in a specific case.

2 The Idea

The idea is not new. A test could be running in a jail --= it provides the
required isolation with minimum or zero effort from a test.

3 The Implementation

There is a lot of work done already and the working patch= passed the initial
review (thanks to markj@ and ngie@). [2]

It adds a new concept to the Kyua framework -- an executi= on environment. Two
new metadata were added for that: execenv and execenv_jail.

execenv is a switch to select an environment. If a test's= metadata defines
execenv=3D"jail" then Kyua will create a temporary jail, run such test wi= thin
it, and remove the jail. If execenv=3D"host" is provided or execenv metad= ata is
undefined then Kyua will run such test as it does today.

execenv_jail metadata takes effect only in case of execen= v=3D"jail". It allows a
test to request specific parameters for its jail. These parameters are si= mply
arguments to jail(8), e.g. execenv_jail=3D"vnet allow.raw_sockets".

4 The Adoption

ATF based tests can easily define this new metadata via K= yuafile or directly,
e.g. for atf-sh based tests:

test_head()
{
atf_set descr "Test foo in case of bar"
atf_set require.user root
atf_set execenv jail
atf_set execenv.jail vnet allow.raw_sockets
}

Non-ATF based ones will do it via Kyuafile. Our test suit= e does it through a
Makefile:

TEST_METADATA+=3D execenv=3D"jail"
TEST_METADATA+=3D execenv_jail=3D"vnet allow.raw_sockets"

The patch got some little evolution, I started with a sin= gle execenv_jail
metadata, and during the patch discussion and review, I ended up with two=
knobs: execenv and execenv_jail. It turned out to be a cleaner and less t= ricky
interface such way. The evolution reasoning can be found in the history o= f the
respective Differential. [2]

5 MFC Concerns

For now, I see at least one issue from the usual project = workflow perspective.
Let's imagine that the Kyua framework got this execenv feature committed = to
15-CURRENT, we started to convert existing tests and create new ones to u= se
execenv=3D"jail". If some feature or a bug fix needs to be ported back to=
14-STABLE or 13-STABLE, then "old" Kyua without execenv feature will fail= to
run such tests:

kyua: E: Load of 'Kyuafile' failed: Failed to load Lua fi= le 'Kyuafile': Kyuafile:9: Unknown metadata property execenv.

From a combinatorics perspective, the first three options= pop up to deal with
that:
a) Patch Kyua the same way for the supported STABLE branches so it will b= e
able to run back ported tests based on execenv=3D"jail" (it's not system = ABI
change after all)
b) Exclusively patch Kyua framework for the supported STABLE branches to
simply skip such tests (does not look to provide much benefit)
c) Do not back port tests, only the fix/feature itself (kind of a bad ide= a)

6 The Demo

My test environment showed promising run time numbers for= almost the whole
test suite (ZFS excluded). One of the tests yielded 36 min with test
parallelism improvement versus 1 h 25 min without. In my case with 8 core= s,
the suite runs about 2 times faster with the improvement. [3]

7 Action Points

My current vision of the plan looks as follows:
- [ ] community: Review, testing, comments -- probably we want to change = the
design
- [ ] committers: Help with the main commit -- it should hit freebsd/kyua=
GitHub fork first [4], then vendor branch, and merge to
main after
- [ ] igoro: Provide the subsequent PRs to separate FreeBSD specifics and= fix
existing Kyua tests
- [ ] igoro: Provide the PRs to add brand new tests of Kyua itself to cov= er
the new feature
- [ ] igoro: Provide the respective documentation updates
- [ ] igoro: Migrate some of the existing tests for the start, e.g. netpf= il/pf
- [ ] committers: Help with review and respective commits/merges

The plan is not strict, it depends on the discussion and = interest of
volunteers.

I hope that this proposal is found valuable for the proje= ct. If so, any help
is appreciated.

[1] New tests exclusivity concern: https://reviews.freebsd.org/D42314
[2] The Kyua patch: https:= //reviews.freebsd.org/D42350
[3] The whole test suite demo: https://reviews.freebsd.org/D42410
[4] The respective PR to the fork: https://github.com/freebsd/kyua/pull/224


Best regards, Igor.

--=_MailMate_F71C8465-E854-4AF9-9342-2B9110ED52D5_=-- From nobody Fri Mar 22 15:48:21 2024 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 4V1RZC71bPz5FCWt for ; Fri, 22 Mar 2024 15:48:35 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V1RZC1vYxz4RrP for ; Fri, 22 Mar 2024 15:48:34 +0000 (UTC) (envelope-from nonesuch@longcount.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount.org header.s=google header.b="pxIeWH/B"; dmarc=none; spf=pass (mx1.freebsd.org: domain of nonesuch@longcount.org designates 2607:f8b0:4864:20::e29 as permitted sender) smtp.mailfrom=nonesuch@longcount.org Received: by mail-vs1-xe29.google.com with SMTP id ada2fe7eead31-4739b6ddc94so314168137.0 for ; Fri, 22 Mar 2024 08:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount.org; s=google; t=1711122514; x=1711727314; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=x/mnZcn3un4SrLP2uSYWfHfg8Px+gFqd6BG1rqXx6fw=; b=pxIeWH/B9ByF4Csi6GJmn8u/L3htLkQg1zwgnpgRVUbo+HW6CLEcVzn7HhUNLB14sV oXeCaPCaBkJ7MDeMAMtqMtxYcq+VDpcMBZ8hOdwA3ujJP24Vn1Fjhv8jV5DcRPy025Uj 5vVr1IweE7Xhg1RjeFGrQ9mpMMidmbQQRj6zgiunQnb7nkTM1bHvGWRPX0XbDvhGL/f7 IYviG9v9vQXUCwnHO5lzB+yydGv/XfKEdeHn//t7bJdaBOHuCoCvGZTZexzLqP3E/deV /mbC3EwznacjnF/b4W159P1mnh4D901yNqnDvpzsTkgg9G8iAGns13aC5WDxkCefr9Zv amIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711122514; x=1711727314; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=x/mnZcn3un4SrLP2uSYWfHfg8Px+gFqd6BG1rqXx6fw=; b=odVttXTU8cmaC3IJzovAZ9l45nU2Hnis3Z4jhiYCI5uJ2t8OvXSNvDoE8diWjDe4tL fdXgZEmK8p5O6JqRKf7c19MqJDiO1YK6OmJEhbkmmNVyPq0osE+7nsGVhSeZfj0vBDvA ppmmyNgvSSOFWdrl18yyj2XdYq5ynOhVyUX+ZMRkyOphGo4fpuuXSIy3VJqDu/Gkb7X0 b+2oG9REvrfFDyr9ybMv28pyRcEiRCK4sD+dKSYYD9p55bKAJC+eStoaO2F6a3xG3MlJ +7AzEFthGgMNZreXOyCv3GowpJvpSUMGx1335FD4/A2UdZSuhEDx5DqeZd5cKNCaoY2l 25qA== X-Gm-Message-State: AOJu0YwFjG6ACRSo6rCk86idbHj3yi9dURC9ROVHIqKQ/ijfb8qEuKu/ Bxjp8R5LJV0Jf2WxuprugagBRODqJWJ7ai6s3QRctgFuW6o9ARsBQFJs1lKxTUclUJFVkypgioc w8niuOZa9jPmpCJOpPeW/uMOpuVitTW8AdN5PrEbwBSA0WprbZIc= X-Google-Smtp-Source: AGHT+IHWv2XEaa4nvbR8+DdMybsYXtu98gqgrpg0MsvrCmcvkxQawLNf0eDcvdReDXy+CGf80hpPJ8+JOtqaiM2vZrw= X-Received: by 2002:a05:6102:34ee:b0:476:ddfa:c511 with SMTP id bi14-20020a05610234ee00b00476ddfac511mr759287vsb.23.1711122513680; Fri, 22 Mar 2024 08:48:33 -0700 (PDT) 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 From: Mark Saad Date: Fri, 22 Mar 2024 11:48:21 -0400 Message-ID: Subject: TarFS To: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000988c1a061441c1fc" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[longcount.org:s=google]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[longcount.org]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[longcount.org:+] X-Rspamd-Queue-Id: 4V1RZC1vYxz4RrP --000000000000988c1a061441c1fc Content-Type: text/plain; charset="UTF-8" Hello All, I was wondering if anyone has started to play with tarfs in FreeBSD 14 ? It appears to puke with larger tarballs. For example , if I fetch a copy of ports or pkgsrc and decompress it to just a posix tar archive I can't get it to mount. root@mono:/home/nonesuch # file ports.tar ports.tar: POSIX tar archive root@mono:/home/nonesuch # mount -t tarfs ./ports.tar /tarfs/ports mount: ./ports.tar: Inappropriate file type or format root@mono:/home/nonesuch # file pkgsrc.tar pkgsrc.tar: POSIX tar archive root@mono:/home/nonesuch # mount -t tarfs pkgsrc.tar /tarfs/ports mount: pkgsrc.tar: Invalid argument root@mono:/home/nonesuch # ls -alsh ports.tar 585312 -rw-r--r-- 1 nonesuch nonesuch 571M Mar 22 01:01 ports.tar root@mono:/home/nonesuch # ls -alsh pkgsrc.tar 567360 -rw-r--r-- 1 root nonesuch 554M Mar 16 01:29 pkgsrc.tar Before I open a bug here, is this expected ? -- mark saad | nonesuch@longcount.org --000000000000988c1a061441c1fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,
=C2=A0 I was wondering if anyone= has started to play with tarfs in FreeBSD 14 ? It appears to puke with lar= ger tarballs. For example , if I fetch a copy of ports or pkgsrc and decomp= ress it to just a posix tar archive I can't get it to mount.
=

root@mono:/home/nonesuch # file ports.tar
ports.tar= : POSIX tar archive
root@mono:/home/nonesuch # =C2=A0mount -t tarfs ./po= rts.tar /tarfs/ports
mount: ./ports.tar: Inappropriate file type or form= at

root@mono:/home/nonesuch # file pkgsrc.tar
pkgsrc.tar: POSIX tar archiv= e
root@mono:/home/nonesuch # =C2=A0mount -t tarfs pkgsrc.tar =C2= =A0/tarfs/ports
mount: pkgsrc.tar: Invalid argument

=
root@mono:/home/nonesuch # ls -alsh ports.tar
585312 -rw-r--r-- = =C2=A01 nonesuch nonesuch =C2=A0571M Mar 22 01:01 ports.tar
root@mono:/h= ome/nonesuch # ls -alsh pkgsrc.tar
567360 -rw-r--r-- =C2=A01 root nones= uch =C2=A0554M Mar 16 01:29 pkgsrc.tar

Before I op= en a bug here, is this expected ?


--
mark saad | nonesuch@longcount.org
--000000000000988c1a061441c1fc-- From nobody Fri Mar 22 17:51:29 2024 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 4V1VJL48hfz5FRpD for ; Fri, 22 Mar 2024 17:51:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4V1VJJ22GTz4ksq for ; Fri, 22 Mar 2024 17:51:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=c6bhlj++; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1711129901; bh=1aWIJMa/oLOp7vAv1pevWgqYQBkFI5nZ0N+DZRPZEMw=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=c6bhlj++IRbgEsIgP//lC2rwgyQJ/fCqTSShau0Qep8c5rToBcwenlNF9yGXvtBehdqitouSRWSrDJj9BoxZQ1BtaOcFNCBqRNQMQ7JsU36Uy0ou9N5+1PBxuHfkUwbSbRd3lyX0DGe4ow1JHmERiirZgSsyNWRoyxWETj+W8uUXxupVcdVuQmhcBqmPlJ6lx0yetT35WBnaWg8L5XLOYz+G1MUR5gE00MS+Vmwug8n7GSxXA+VzUPa2I85gYpWjyc+iDB0GmWZZGf4fWYUnq9vOtsPxrvOvEd4MPoJqPhjjSQgwnxsyO+2ge5BYcOED5K4FCeLhxHjo5k8S8iHicQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1711129901; bh=KrzxLO5WClMXwr/9eeiXQowZYFyVS59/BypP7QyZkZE=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jn+0x5qsXqB3C/xkecfEPk41RduraRBzWvbh0IjZWzn8RolXRfVfvpr+xAVXBqHECyAD6cye1Zd0YME5yu4jBQrcbmzpHSBCPS/dJGEhAHtbKIsjrCd3CHDvwQgPrXtRjjmvkR/hLZaCakG9z64HfCx2CNq1rjxWtme/x09epStVYMR7rDt00Hc7D9PghAwAZOjhazost1bsMTpG/N84MROTE2RwhFYvz0FkPch3Z1TToZXnaFM0Jm9KJ935YbRkE3t85RVcYP1NiJFl1tD8tIVq3CZ5tnalfqDuxs1cupq1fyW2P1974M2ASmWwx0obXiMD16pwMWdsyAuokq5TTw== X-YMail-OSG: 6q8XTFQVM1k9VDGiiUXORstDeGxkF1Y98M8Q.AxRyrcoAIm9y8wsucGb.9REsJ0 bnDW69EuUfDPWqy3xTLf0ePCOtMHwCcs7MjuBkv2oBuKWnufv7T3JFC.5OxlJ1.fMGlztibHIukJ .xiB0dUm32MOfW8DsRBH_.Dr7SCDWCrrj5yStNT8tkrS7w2RGCsrg45dJOO.3_TWRYQpshwGyVQ1 3BU3RJdxDixsQ.0TE6hL5WF28otEfCWPIjTKw2p8ECJCKBPFtCwLJZVQ7P8seud4avxoOsU4wed6 Qaa9jiq0Wa37GvDvSAeYG3WxGJpWV7LAxNVePtTWY59GLpkq2BN7HXkCWJiawqtTghJn05pN8i1T c2kTdBLVaCZFckXV5gC2TE51NSsMXsmX0BwjRu.Og.Qr05uLlVogEBGXSybSlbR48tJovchPf7r9 gA3E1B9BtGi2j8zSi2XmLt4IcrUCbFbee9g.beGwHlCmUSkC5TDnxZyfy8TwTzRdmKhtCqqvpy3X WVGXApTUbWIt.NR3YqQ9zl.cp_eiOxZSChw4QKNbO_lYgzPRaCyIY_JDF4LEMTzxxeWNv_dz9LIm LFzUodlXJXifaCl1ZVPD_NBSFnLq8BgBaA_Y.6nE_vwx9e0zXG_WQhrtnMt.JD5E8ceTMbBs5SK_ Bor0jiLWRC9gPYp60sTKn7r3sFdIzZaBLnQb7f7cwsBiZHTE6d07XT_wLLFvKzzzWe3qCPQ.08fy fI537VgUSa.vp0jUM2RTwz68_dUMmTyo910OuR7HE8HR10acYRZiPHyENk0mjDKV.BspeCIoMWpW XdwH2K1Twbk0LI4Gbz0e9vsBIUs_ULxEOVNtbYM6.86M1PLB.AS5R4KCMTtzAQt2hPXzEoFVFUyT oCc36euXOlLQT9SHGlWJ_PBV1FPbox0QbRqCicamAUKBBNm3LiEhpRARsTlasrfHWTXL6MeF34fn zlJ8FvUxd0O9efRpbilvhqHFqK_7CmvgEkEkilWNtzXVCX9haP7sNmoDmZrvCX_4RWB7h0Or8kmq xQK6SdiUs0aENbEd9tvp36FffGpVShCMHIN2MBEWzc7yo.987iUmI593r8uxxK4YQKdqsOaMUYnT 1009dHu4aO.ZAghp6fff5mDEJRA30fAPOMHI4tlNxhAIUGR3QTnH696oKPScw53pH9e0H9Nt2KC9 KEIRx_0kFJF1lp0P7uFDgwUab3YbcsLqkARNIpv0PPPybHxp4wVTsmzt60ywLOTpN8yb6VPD8HQL FoBwgYUl6nQFWb4NHDKyRuQxjM5XJfSvBDvT2LfnoXdCJJm0RFZ2tuQ0TICrs6PvRuA0l1oapR4J Qezvsk6eYZhd2Z8gdyPVELtd06IxvzEP_WzlD9QWEIwjD..BlavD5jRRSbENm6STY_uYFs.1sx4A mMq.tCxq7x7gvUtpP79xVnU9wWPbAR3jsT8PpVH9a6P._p4GANahvdEeVko1LkmtoZ9PBTkA8S7v adqVousdUXlVFEjQ1PYvgJtEtU0lfobvUK1KY.Mot3bbmgfqTnuSRfP6LpAm_fmC8dKRwPH3ESlQ 2db.1NSb7CbWUXbcf_Mp4.VjGjtxS4VMsw5enPtNDfkUBPcArZN21z3FyYbkmT4LF_fcP3LNC49V zgSa0jeZReD5TxgGQCEMOisQbEH98pMLBes18SP4uyf3sZXtc7QGyFvjEZtqhjoZwUOYXK1tCbmF bIWE8UnG1_o5L9izNZu.u_OfPyc2D10TgieK0THxD_6oaiBzYK426Qgw83woMThdx_RY1sVF.VZq lFJRjr2yvR8bDj26AKW1LCB80qqTWryPHr8Bii7Zc30rk5lGIMcTNQGpYu2XSgBPtOx7TyJ67lLU Iic9OhhM6HilTxOCCXRCtlvhbt0_BMA0NjugnJNv92WznaJuLUth3iQTmqVSnnqOqwtZZObVODE5 WftSTs6FiUAM4cgBCF4ZtP3.nodwlsPfs4La0PtmRohc8KVNTpZ4hPPJtW1OFO.avHaj6Nrg0kil F_y_u5f7_im7zYfZmx.MPdHDqrNriTpJ0T2KokQHwj9RWIQgY8tvnh5ZtKD_lKKaC7E5EjC3p1zG kNGKdFqnBWInev1tKK4CXWHS4yia0BsHB9P55o12vh8CH.9XUIoDqYv.YkRYw5R5BaruiudqrVNE D6tziRjPe0PbxRdFiZ36pT8gQJDtwOBWo_B4NJgrS.tAKfJRiFJ9J8Vo3F6lJZqirXXP7rk1GSPn FQaEXAvg4WlTZ9jEoCwzQKG9oPLY8aDm.sGKEP05cG08Ytf5gru0Wp1XKv6T_Y1ZwieZqWZpQSUo - X-Sonic-MF: X-Sonic-ID: cd50f23f-2f10-456e-bb91-95607f1b228c Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Mar 2024 17:51:41 +0000 Received: by hermes--production-gq1-5c57879fdf-7xbd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1dc08150cd34a0f1c37357c36ebc178f; Fri, 22 Mar 2024 17:51:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: main aarch64: poudriere-devel [UFS context] cpdup stuck in pgnslp state [any more useful information to extract via kgdb?] Date: Fri, 22 Mar 2024 10:51:29 -0700 References: To: freebsd-hackers , FreeBSD ARM List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; SUBJECT_HAS_QUESTION(0.00)[] X-Rspamd-Queue-Id: 4V1VJJ22GTz4ksq [Adding some information from kgdb. Switch to freebsd-hackers and (still) freebsd-arm. I also ask if there is more useful information to extract via kgdb.] On Mar 21, 2024, at 17:34, Mark Millard wrote: > Note, more recent process creations towards top, older ones towards = bottom: >=20 > PID JID USERNAME PRI NICE SIZE RES STATE C TIME = CPU COMMAND > . . . > 33693 19 root 68 0 6524Ki 3252Ki wait 3 0:00 = 0.00% /usr/bin/make -C /usr/ports/lang/gcc13 build > 33692 0 root 68 0 15728Ki 3552Ki wait 0 0:00 = 0.00% sh: poudriere[main-CA7-default][02]: build_pkg (gcc13-13.2.0_4) = (sh) > 30174 0 root 68 0 15728Ki 3564Ki select 3 0:00 = 0.00% sh: poudriere[main-CA7-default][02]: build_pkg (gcc13-13.2.0_4) = (sh) > 26338 0 root 66 0 17740Ki 5044Ki pgnslp 0 0:01 = 0.00% cpdup -i0 -s0 -f -x ref 01 > 26308 0 root 68 0 15728Ki 3556Ki wait 0 0:00 = 0.00% sh: poudriere[main-CA7-default][01]: build_pkg = (boost-libs-1.84.0) (sh) > 33592 0 root 26 0 15728Ki 3388Ki piperd 2 0:01 = 0.00% sh: poudriere[main-CA7-default]: pkg_cacher_main (sh) > 29205 0 root 68 0 15728Ki 3392Ki nanslp 2 1:52 = 0.14% sh: poudriere[main-CA7-default]: html_json_main (sh) > 28834 0 root 20 0 15728Ki 3548Ki select 3 0:01 = 0.00% /usr/local/libexec/poudriere/sh -e = /usr/local/share/poudriere/bulk.sh -jmain-CA7 -c -f = /root/origins/CA7-origins.txt > 28833 0 root 20 0 13560Ki 1924Ki wait 3 0:00 = 0.00% /bin/sh /root/build-ports-main-CA7.sh -c > . . . >=20 > pgnslp seems to be from: vm_page_acquire_unlocked in sys/vm/vm_page.c = . > That in turn looks to be using vm_page_grab_sleep : >=20 > if (!vm_page_grab_sleep(object, m, pindex, "pgnslp", > allocflags, false)) > return (false); >=20 > and: >=20 > /* > * vm_page_grab_sleep > * > * Sleep for busy according to VM_ALLOC_ parameters. Returns true > * if the caller should retry and false otherwise. > * > * If the object is locked on entry the object will be unlocked = with > * false returns and still locked but possibly having been dropped > * with true returns. > */ > static bool > vm_page_grab_sleep(vm_object_t object, vm_page_t m, vm_pindex_t = pindex, > const char *wmesg, int allocflags, bool locked) > { >=20 > if ((allocflags & VM_ALLOC_NOWAIT) !=3D 0) > return (false); >=20 > /* > * Reference the page before unlocking and sleeping so that > * the page daemon is less likely to reclaim it. > */ > if (locked && (allocflags & VM_ALLOC_NOCREAT) =3D=3D 0) > vm_page_reference(m); >=20 > if (_vm_page_busy_sleep(object, m, pindex, wmesg, allocflags, = locked) && > locked) > VM_OBJECT_WLOCK(object); > if ((allocflags & VM_ALLOC_WAITFAIL) !=3D 0) > return (false); >=20 > return (true); > } >=20 > . . . > [10:08:06] [01] [00:00:00] Building devel/boost-libs | = boost-libs-1.84.0 > . . . >=20 > # poudriere status -b > [main-CA7-default] [2024-03-21_06h23m31s] [parallel_build] Queued: 265 = Built: 213 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: = 52 Time: 10:50:40 > ID TOTAL ORIGIN PKGNAME = PHASE TIME TMPFS CPU% MEM% > [01] 00:42:40 devel/boost-libs | boost-libs-1.84.0 = starting 00:42:40 951.54 MiB =20 > . . . >=20 > Unfortunately: >=20 > A) The booted kernel is my personal build based on -mcpu=3Dcortex-a76 > and LSE_ATOMICS . (It is in use on a RPi5 booted via EDK2.) >=20 > B) The booted world is a PkgBase world. >=20 > C) The poudriere jail's world directory tree is my personal armv7 > world build based on -mcpu=3Dcortex-a7 . >=20 > All are based on: main-n268827-75464941dc17 . (Well, PkgBase > commit identification/verification for world does not exist. > I happened to update PkgBase during a long lull for commits > to main. In the context, the boot-world seems unlikely to be > involved here.) >=20 > The boot media is a U2 Optane 960 GB used via a USB3 adaptor. >=20 > I've done bunches of builds in the (A)-(C) context on the RPi5 > and have not seen this before, so: does not look to be readily > repeatable. >=20 > (Unfortunately, the purpose of the build was to find out how long > the particular build configuration took to finish building the > 265 packages from scratch, for comparison to other builds.) >=20 > I may wait for the system to become fairly idle and then see about > forcing a crash dump. It may be a while before the poudriere bulk > runs out of packages it can build, absent building boost-libs . >=20 >=20 > Side note: > As far as I can tell, how to identify a context that allows > identification of what commit vintage a PkgBase world is based on > is unspecified so far. For a PkgBase kernel uname -apKU may well > report the kernel-commit identification well. (Hard to verify.) The cpdup kernel thread backtrace follows. The kernel build was NODEBUG and optimatized, but with debug information still produced. This can lead to somewhat messy information but is better than not having the information. (kgdb) thread 145 [Switching to thread 145 (Thread 361925)] #0 sched_switch (td=3Dtd@entry=3D0xffff0000dfaf8c80, = flags=3Dflags@entry=3D259) at /usr/main-src/sys/kern/sched_ule.c:2290 2290 cpuid =3D td->td_oncpu =3D PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=3Dtd@entry=3D0xffff0000dfaf8c80, = flags=3Dflags@entry=3D259) at /usr/main-src/sys/kern/sched_ule.c:2290 #1 0xffff0000004f5f2c in mi_switch (flags=3Dflags@entry=3D259) at = /usr/main-src/sys/kern/kern_synch.c:546 #2 0xffff00000054ea28 in sleepq_switch (wchan=3D, = pri=3D) at /usr/main-src/sys/kern/subr_sleepqueue.c:607 #3 0xffff00000054e8f8 in sleepq_wait (wchan=3D, = wchan@entry=3D0xffffa001fae26630, pri=3D, pri@entry=3D52) = at /usr/main-src/sys/kern/subr_sleepqueue.c:658 #4 0xffff00000084e768 in _vm_page_busy_sleep (obj=3D, = obj@entry=3D0xffffa0012aab9528, m=3Dm@entry=3D0xffffa001fae26630, = pindex=3Dpindex@entry=3D0, wmesg=3D0xffff0000009c6297 "pgnslp", = allocflags=3Dallocflags@entry=3D21504, locked=3D) at = /usr/main-src/sys/vm/vm_page.c:1100 #5 0xffff0000008548e4 in vm_page_grab_sleep (object=3D0xffffa0012aab9528,= m=3D0xffffa001fae26630, pindex=3D0, allocflags=3D21504, locked=3Dfalse, = wmesg=3D) at /usr/main-src/sys/vm/vm_page.c:4547 #6 vm_page_acquire_unlocked (object=3Dobject@entry=3D0xffffa0012aab9528, = pindex=3Dpindex@entry=3D0, prev=3D, = prev@entry=3D0xffff0000e04c5570, mp=3Dmp@entry=3D0xffff0000e04c55b8, = allocflags=3D21504) at /usr/main-src/sys/vm/vm_page.c:4690 #7 0xffff0000008552c4 in vm_page_grab_valid_unlocked = (mp=3Dmp@entry=3D0xffff0000e04c55b8, = object=3Dobject@entry=3D0xffffa0012aab9528, pindex=3Dpindex@entry=3D0, = allocflags=3Dallocflags@entry=3D21504) at /usr/main-src/sys/vm/vm_page.c:4871 #8 0xffff0000005949e8 in uiomove_object_page (obj=3D0xffffa0012aab9528, = len=3D, uio=3D0xffff0000e04c57d8) at = /usr/main-src/sys/kern/uipc_shm.c:207 #9 uiomove_object (obj=3D0xffffa0012aab9528, obj@entry=3D, obj_size=3D29352, = obj_size@entry=3D, = uio=3D0xffff0000e04c57d8, uio@entry=3D) at /usr/main-src/sys/kern/uipc_shm.c:268 #10 0xffff0000009b8a54 in VOP_READ_APV (vop=3D0xffff000000c8c038 = , a=3Da@entry=3D0xffff0000e04c5658) at = vnode_if.c:1048 #11 0xffff0000005fd630 in VOP_READ (vp=3D0xffffa00129280540, = uio=3D0xffff0000e04c57d8, ioflag=3D327680, cred=3D) at = ./vnode_if.h:537 #12 vn_read (fp=3Dfp@entry=3D0xffffa0007492bdc0, = uio=3Duio@entry=3D0xffff0000e04c57d8, = active_cred=3Dactive_cred@entry=3D0xffffa0010ab5f400, flags=3D, td=3D) at /usr/main-src/sys/kern/vfs_vnops.c:1123 #13 0xffff0000005f5598 in vn_io_fault (fp=3D0xffffa0007492bdc0, = fp@entry=3D, = uio=3D0xffff0000e04c57d8, uio@entry=3D, active_cred=3D0xffffa0010ab5f400, = active_cred@entry=3D, = flags=3D0, flags@entry=3D, td=3D0xffff0000dfaf8c80, td@entry=3D) at /usr/main-src/sys/kern/vfs_vnops.c:1504 #14 0xffff000000562ed4 in fo_read (fp=3D0xffffa0007492bdc0, = uio=3D0xffff0000e04c57d8, active_cred=3D, flags=3D0, = td=3D0xffff0000dfaf8c80) at /usr/main-src/sys/sys/file.h:344 #15 dofileread (td=3Dtd@entry=3D0xffff0000dfaf8c80, fd=3Dfd@entry=3D3, = fp=3D0xffffa0007492bdc0, auio=3Dauio@entry=3D0xffff0000e04c57d8, = offset=3D, flags=3D0, flags@entry=3D-531867712) at /usr/main-src/sys/kern/sys_generic.c:366 #16 0xffff000000562a00 in kern_readv (td=3D0xffff0000dfaf8c80, fd=3D3, = auio=3D0xffff0000e04c57d8) at /usr/main-src/sys/kern/sys_generic.c:287 #17 sys_read (td=3D0xffff0000dfaf8c80, td@entry=3D, uap=3D, uap@entry=3D) at /usr/main-src/sys/kern/sys_generic.c:203 #18 0xffff00000089f9b4 in syscallenter (td=3D0xffff0000dfaf8c80) at = /usr/main-src/sys/arm64/arm64/../../kern/subr_syscall.c:186 #19 svc_handler (td=3D0xffff0000dfaf8c80, frame=3D) at = /usr/main-src/sys/arm64/arm64/trap.c:198 #20 do_el0_sync (td=3D0xffff0000dfaf8c80, frame=3D) at = /usr/main-src/sys/arm64/arm64/trap.c:640 #21 #22 0x00000000271dd394 in ?? () #23 0x0000000026e3071c in ?? () Backtrace stopped: previous frame identical to this frame (corrupt = stack?) (kgdb) frame 4 #4 0xffff00000084e768 in _vm_page_busy_sleep (obj=3D, = obj@entry=3D0xffffa0012aab9528, m=3Dm@entry=3D0xffffa001fae26630, = pindex=3Dpindex@entry=3D0, wmesg=3D0xffff0000009c6297 "pgnslp", = allocflags=3Dallocflags@entry=3D21504, locked=3D) at = /usr/main-src/sys/vm/vm_page.c:1100 1100 sleepq_wait(m, PVM); FYI: . . . } while (!atomic_fcmpset_int(&m->busy_lock, &x, x | = VPB_BIT_WAITERS)); if (locked) VM_OBJECT_DROP(obj); DROP_GIANT(); sleepq_add(m, NULL, wmesg, 0, 0); sleepq_wait(m, PVM); PICKUP_GIANT(); return (true); } . . . (kgdb) print /x *m $2 =3D {plinks =3D {q =3D {tqe_next =3D 0xffffa001fc7c31c0, tqe_prev =3D = 0xffffa001ff85d2d0}, s =3D {ss =3D {sle_next =3D 0xffffa001fc7c31c0}}, = memguard =3D {p =3D 0xffffa001fc7c31c0, v =3D 0xffffa001ff85d2d0}, uma =3D= { slab =3D 0xffffa001fc7c31c0, zone =3D 0xffffa001ff85d2d0}}, listq = =3D {tqe_next =3D 0xffffa001ff85d2d0, tqe_prev =3D 0xffffa0012aab9570}, = object =3D 0xffffa0012aab9528, pindex =3D 0x0, phys_addr =3D = 0x12a816000, md =3D {pv_list =3D {tqh_first =3D 0x0, tqh_last =3D = 0xffffa001fae26668}, pv_gen =3D 0x15fd, pv_memattr =3D 0x2}, ref_count =3D= 0x80000000, busy_lock =3D 0x1, a =3D {{flags =3D 0x208, queue =3D = 0x1, act_count =3D 0x1}, _bits =3D 0x1010208}, order =3D 0xd, pool =3D = 0x0, flags =3D 0x1, oflags =3D 0x0, psind =3D 0x0, segind =3D 0x8, valid = =3D 0xff, dirty =3D 0x0} Any more potentially useful information to extract via kgdb? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Mar 22 18:54:06 2024 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 4V1WhY6CYzz5F5gx for ; Fri, 22 Mar 2024 18:54:21 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101: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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V1WhW74lfz4vVq for ; Fri, 22 Mar 2024 18:54:19 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=kbOAuUB3; dmarc=none; spf=pass (mx1.freebsd.org: domain of ticso@cicely7.cicely.de designates 2a02:21e0:16e0:fe::101:1 as permitted sender) smtp.mailfrom=ticso@cicely7.cicely.de Received: from mail.cicely.de (mail.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:c]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 42MIs6LB069363 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL) for ; Fri, 22 Mar 2024 19:54:09 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1711133649; bh=V+lyRBikAGslTqP6vYuECNTmM6vg07Lie+ua+qKUpvA=; h=Date:From:To:Cc:Subject; b=kbOAuUB3LwWGj4Uk2a4L9+lxocTPFIwB26+6nTLO8FOpCd1a9+Sg8KAXpvDQsDT2F M0xgjNyA6HM0rBUOsC2AzJThQI66/TdYr4u/v4iH+nd86YUlbRslgjnn1du16h/i8Q NjJnYz0L96ClTzDQG8Xzw7WzOEA175Vd19alWOQ8= Received: from cicely7.cicely.de (c7-old.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:d]) by mail.cicely.de (8.16.1/8.16.1) with ESMTPS id 42MIs6gW062039 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Mar 2024 19:54:06 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.17.1/8.17.1) with ESMTP id 42MIs6Z2039675; Fri, 22 Mar 2024 19:54:06 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.17.1/8.17.1/Submit) id 42MIs61w039674; Fri, 22 Mar 2024 19:54:06 +0100 (CET) (envelope-from ticso) Date: Fri, 22 Mar 2024 19:54:06 +0100 From: Bernd Walter To: freebsd-hackers@freebsd.org Cc: Bernd Walter Subject: Only 1TB RAM out of 1.5TB on amd64 Message-ID: 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 X-Operating-System: FreeBSD cicely7.cicely.de 13.2-RELEASE-p3 amd64 X-Rspamd-Server: rspamd.fizon.de X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FORGED_SENDER(0.30)[freebsd-hackers@cicely.de,ticso@cicely7.cicely.de]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[cicely.de]; RCVD_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cicely.de:+]; FREEFALL_USER(0.00)[ticso]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[freebsd-hackers@cicely.de,ticso@cicely7.cicely.de]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:44700, ipnet:2a02:21e0::/32, country:DE]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4V1WhW74lfz4vVq ... real memory = 1649265344512 (1572862 MB) avail memory = 1057138888704 (1008166 MB) ... I suspect address space issues, but don't know for sure. Changing NUMA nodes per socket in the BIOS had an influence to make it worse, but not better. Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64 FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367) VT(efifb): resolution 1024x768 CPU: AMD EPYC 7352 24-Core Processor (2300.07-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x830f10 Family=0x17 Model=0x31 Stepping=0 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x75c237ff Structured Extended Features=0x219c91a9 Structured Extended Features2=0x400004 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x18cf757 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 1649265344512 (1572862 MB) avail memory = 1057138888704 (1008166 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs FreeBSD/SMP: 2 package(s) x 8 cache groups x 3 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-23 ioapic1 irqs 24-55 ioapic2 irqs 56-87 ioapic3 irqs 88-119 ioapic4 irqs 120-151 ioapic5 irqs 152-183 ioapic6 irqs 184-215 ioapic7 irqs 216-247 ioapic8 irqs 248-279 Launching APs: 32 30 34 13 14 16 23 21 19 24 28 9 86 10 87 7 26 37 39 41 45 46 43 66 71 69 54 57 59 80 82 78 49 53 51 60 65 62 84 88 91 95 74 73 76 92 33 40 11 2 27 22 20 5 44 18 15 36 6 8 25 89 79 85 93 56 48 70 31 81 12 50 38 77 55 63 75 58 1 90 29 94 52 72 67 83 35 42 61 64 68 47 4 17 3 random: entropy device external interface kbd1 at kbdmux0 ... kern.maxphys: 1048576 hw.physmem: 1099322220544 hw.usermem: 1091323355136 hw.realmem: 1649265344512 vm.phys_locality: 0: 10 32 1: 32 10 vm.phys_segs: SEGMENT 0: start: 0x10000 end: 0xa0000 domain: 0 free list: 0xffffffff81ec7ea0 SEGMENT 1: start: 0x100000 end: 0x1000000 domain: 0 free list: 0xffffffff81ec7ea0 SEGMENT 2: start: 0x1000000 end: 0x74000000 domain: 0 free list: 0xffffffff81ec7c30 SEGMENT 3: start: 0x74043000 end: 0x75db0000 domain: 0 free list: 0xffffffff81ec7c30 SEGMENT 4: start: 0x76000000 end: 0x963b8000 domain: 0 free list: 0xffffffff81ec7c30 SEGMENT 5: start: 0x963c2000 end: 0x963f9000 domain: 0 free list: 0xffffffff81ec7c30 SEGMENT 6: start: 0x96500000 end: 0xa57f7000 domain: 0 free list: 0xffffffff81ec7c30 SEGMENT 7: start: 0xa8e96000 end: 0xac000000 domain: 0 free list: 0xffffffff81ec7c30 SEGMENT 8: start: 0x10000e000 end: 0x7d07800000 domain: 0 free list: 0xffffffff81ec79c0 SEGMENT 9: start: 0x10000019000 end: 0x1797de00000 domain: 1 free list: 0xffffffff81ec8110 SEGMENT 10: start: 0x17ffdc00000 end: 0x17ffdde7000 domain: 1 free list: 0xffffffff81ec8110 -- B.Walter https://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From nobody Fri Mar 22 23:37:56 2024 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 4V1dzs6DLFz5FfpB for ; Fri, 22 Mar 2024 23:38:01 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V1dzr4S0Zz4Sqb for ; Fri, 22 Mar 2024 23:38:00 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=Id305TZ9; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::135 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-il1-x135.google.com with SMTP id e9e14a558f8ab-36867dfe940so7811435ab.3 for ; Fri, 22 Mar 2024 16:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1711150678; x=1711755478; darn=freebsd.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=3/wG0uOEB1CeKEdE6UBypaypkxqNXmPALJ72s3w6OC8=; b=Id305TZ9olCDK37rNUb9PhUW3WHZWVRhNKoGOM6XXQ49TJ0PA0RI6YzUKQdxlohreT jGXbk0FhAPprqPzQ9yPjDPcK7DedqLhCSXOEOYbpoGDD2Hbn7qmDslgnJ3tN/npaPyuH CGKNN1/Lzt6iuja+fkPpZQdGcbwrqvcQGpifoUJ1muRBK5epdE+CAa57t5aFNFb4bzQD cvVHrseXmCtn7l2ZJ2tOKQHd3RJfQ8Uk3KNZg+TKm0ZRC2PiCUwiTynX/hW7Sx1C9wJv K6QzhA0zjkOoIFBldGZN1rRoAYRLnau7YmCz/nPIg9jFhFYGjR9ertjqHumi4nheg5ex VKjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711150678; x=1711755478; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3/wG0uOEB1CeKEdE6UBypaypkxqNXmPALJ72s3w6OC8=; b=gloRKfVZMjJ22kQneSxB22NTPBf+pnORNh8+qVQ1qBB/XVaqMm4Jv13L6S0UPHwCqY ripfb6T0+qfqwURRHdhjzagpOdaV+AzS3jEJj4dd2SsBnxsXaYktX23K77sH+Apm+pic XByIhRS4n2MnR6TJDTkBeWndmBgCGy34Z8la7zPsbxYaf+xWX+tOSB7I5RxkJezRaacE dItkg59OwQ/KRT+HiUwu7xM7HpqbWcFlSb9yDoq9TqxMYCHm5wPFr5od4k7/2iHOPuOX bYps1xkcAUZ3rTGO0OY3jadrwZJ4oTPMTJv7gMNBxFlPMLapPw4hz52lAZr7o0r2Kdft q23Q== X-Gm-Message-State: AOJu0YyRYFxLucv3ttfaBDmWx/oU0gkclnxr7p6A7q1LIfQh8VF7hfpy /++C0dDCxAo8ZpgUxYv+Os/TrUH0Zjh5/GgKzly1S8gsGgYT2cjO60n6Jz0oZm1/0+CjBldV9ga 4ZUk5fmpTQe6zTqDYaakRdxFDxO+DR+hEDsJFPDPTP9kr/bJGAalXhom0p3AfsOYX0tAkCkP8Y1 0LLZAm+UY44XxWFFc3/d5kslLpmWdzFIcuKfpPjm6TgcnnfULXmcKt X-Google-Smtp-Source: AGHT+IEAdFKsJjcSFGGnVv6PbS4IrNrro587vDfmKTYC7LKinAFNtDSChI1R3ruJvI8X/1dfkHmffA== X-Received: by 2002:a92:db01:0:b0:368:747a:9049 with SMTP id b1-20020a92db01000000b00368747a9049mr1041549iln.2.1711150677584; Fri, 22 Mar 2024 16:37:57 -0700 (PDT) Received: from mutt-hbsd (174-24-72-211.clsp.qwest.net. [174.24.72.211]) by smtp.gmail.com with ESMTPSA id w15-20020a056e0213ef00b003687e0f19afsm44669ilj.65.2024.03.22.16.37.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 16:37:56 -0700 (PDT) Date: Fri, 22 Mar 2024 23:37:56 +0000 From: Shawn Webb To: freebsd-hackers@freebsd.org Subject: Filesystem extended attributes and Capsicum Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="znjzrhotgeqp5oaq" Content-Disposition: inline X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.09 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[hardenedbsd.org]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::135:from]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+] X-Rspamd-Queue-Id: 4V1dzr4S0Zz4Sqb --znjzrhotgeqp5oaq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey all, I'm writing an application in which I hope to enable Capsicum. I'm experiencing an issue whereby extattr_get_fd fails with a file descriptor that has all the extended attribute capabilities enabled (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and CAP_EXTATTR_SET). Looking at the kernel source (sys/kern/vfs_extattr.c) tells me that kern_extattr_get_fd only requires CAP_EXTATTR_GET. So I'm a bit puzzled as to why my call to extattr_get_fd(2) is failing. Am I doing something wrong or are filesystem extended attributes not supported in a Capabilities-enabled process? Here's how I'm creating the file descriptor (before calling cap_enter(2)): =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D static int open_file(const char *path) { cap_rights_t rights; int fd; fd =3D open(path, O_PATH | O_CLOEXEC); if (fd =3D=3D -1) { return (-1); } =20 memset(&rights, 0, sizeof(rights)); cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, CAP_EXTATTR_SET); cap_rights_limit(fd, &rights); return (fd); } =3D=3D=3D=3D END CODE =3D=3D=3D=3D Eventually, after calling cap_enter(2), the following code is called: =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D #define ATTRNAME_ENABLED "hbsd.pax.aslr" sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME_ENABLED, NULL= , 0); if (sz <=3D 0) {=20 if (errno =3D=3D ENOATTR) { /* * This is okay, it just means that nothing has been= set. * No error condition here. */ return (RES_SUCCESS); } return (RES_FAIL); } =3D=3D=3D=3D END CODE =3D=3D=3D=3D For reference, the program's code is here: https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?ref_type=3Dheads The library code, which is what's responsible for calling the filesystem extended attribute related syscalls is here: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/hardened/current= /hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads =46rom the rights(4) manual page, I'm instructed all I need are to apply those capabilities to that file descriptor: =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). CAP_EXTATTR_GET Permit extattr_get_fd(2). CAP_EXTATTR_LIST Permit extattr_list_fd(2). CAP_EXTATTR_SET Permit extattr_set_fd(2). =3D=3D=3D=3D END PASTE =3D=3D=3D=3D So I'm a bit unsure if I'm doing something wrong. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --znjzrhotgeqp5oaq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmX+FkwACgkQ/y5nonf4 4fprhxAAoDCJ/T6dut1kQvt63wy48bjeDjrtrIziKs0F03nQKzQHEi2BHl97Syc+ LyqsxEGaxQtMRV8I4mGCqXk+uazKxLiz43H8GM1ln2kpI6xVGWqENdTVhQJdYyBn 8cpTw7hxJSsrY31Qio4Mjs4WQKdyYdHCwXAaTMloIo/uNT9HJ6ZXn4HZIgxUq/5k cKB9AbURFWqR9czMNriHnRxOIuV58cd0OO2LEssprwS6NOYp3U5td1cgml8CKbWM Nx2oRnwMYwOigDTmLHSfilUV2crqwfB+/jcICPO7cPZ9GIP4xRNulNQ6pmqTsW8k AiBzMtLKxbSn/HfXCGa6eWURDuDMrM3JzfxTbD+J9Fo6CYW58mIDQsKmxDi42n/M FQJDPLOX66MlXhM3ewxxKgtAU1lYFxfsOe8pi4BrMJVwiea9HJHLKrDqvvV8+TyI RCelE7aPT4ipYcs7D08FfT8PB4arLhImcDUE7Nfk8zbiymHMfoqPzomr0U5KE9Mc mi+u7pl1UiESSUsTDY68Wxu5xDlkK9lr4RctI90kuyoKs5SYHXf10rAicYxXDw2X LZKUYUSlAg6HHNQCxtcUkLcd8Hnfw3GkrWRjwjZ/uYzJMAq0zaNyy26XsdCcFq0G pmOpjxe19B5OS0wBsuB2DIT3CP8vmEin948x0OAR/FMInpUS71w= =2waD -----END PGP SIGNATURE----- --znjzrhotgeqp5oaq-- From nobody Sat Mar 23 00:20:48 2024 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 4V1fxW1Jh5z5FkDh for ; Sat, 23 Mar 2024 00:21:03 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V1fxT5lhMz4XC8 for ; Sat, 23 Mar 2024 00:21:01 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4d43ec959f8so810007e0c.1 for ; Fri, 22 Mar 2024 17:21:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711153260; x=1711758060; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ftqntQhsAY0a0LyNc3x1rxsNLlXVLNShqSARsZY5DfU=; b=WvISKt5UDzvK5b3oFkrHrbJib1i6cBkZO7zTV9xkrr7WUVcBUDCRla5eJZb7LMz7Wp 9GqihRI3TviFFwT6i2Z/TJoYXbomRgJnBUoUeM0ArIVPCPY3PBmTI+KHsDMABThKfIh5 gU98oyYQ+IwtdRuWDfWNtZrxkqvmnbggoIWEcJpx2P/Rg45WuNf28i0Y8O68qn4wBG0n jnYeYAUt1xotZ8/WDwVhh0MkoPAiItRivzu1HUigPm3OKgF3b8w2GA3W/IVI7EaQz3sf yagRK0f1GlQkUVbOMyWuFcPBMvpSXqC2EFTYRWKXVSfltJhaNqBkSAFSDB8WGd6yTZUr G0kg== X-Gm-Message-State: AOJu0YwocDxefWXpu2Fl6Lp5F81/7tbPjTcGNkm5PfNWD4s7ot2IzB4H iJWeIbT6CzmhBKcILS+6VnoxXEkuhb5tzGKRhL/6WMEzSKz6kww9oYvhKn0DzIy7oss82dzAX7R +DXQ8Kr5BD4oP9KQVg3gwXnoMU7hE/L9RhNE= X-Google-Smtp-Source: AGHT+IHOctoYpHNKPPE53jFhcmQx3mr5J6P9k9k6G10tdp+LzAiYhcI2HAvoc+w+68WbGJXxgAMOQp8axOjN775Br1g= X-Received: by 2002:a05:6122:1a98:b0:4d4:21cc:5f4f with SMTP id dy24-20020a0561221a9800b004d421cc5f4fmr850395vkb.11.1711153260631; Fri, 22 Mar 2024 17:21:00 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Fri, 22 Mar 2024 18:20:48 -0600 Message-ID: Subject: Re: Filesystem extended attributes and Capsicum To: Shawn Webb Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4V1fxT5lhMz4XC8 On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > Hey all, > > I'm writing an application in which I hope to enable Capsicum. I'm > experiencing an issue whereby extattr_get_fd fails with a file > descriptor that has all the extended attribute capabilities enabled > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > CAP_EXTATTR_SET). > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells me that > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > So I'm a bit puzzled as to why my call to extattr_get_fd(2) is > failing. Am I doing something wrong or are filesystem extended > attributes not supported in a Capabilities-enabled process? > > Here's how I'm creating the file descriptor (before calling > cap_enter(2)): > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > static int > open_file(const char *path) > { > cap_rights_t rights; > int fd; > > fd =3D open(path, O_PATH | O_CLOEXEC); > if (fd =3D=3D -1) { > return (-1); > } > > memset(&rights, 0, sizeof(rights)); > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > cap_rights_limit(fd, &rights); > > return (fd); > } > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > Eventually, after calling cap_enter(2), the following code is called: > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME_ENABLED, NU= LL, 0); > if (sz <=3D 0) { > if (errno =3D=3D ENOATTR) { > /* > * This is okay, it just means that nothing has be= en set. > * No error condition here. > */ > return (RES_SUCCESS); > } > return (RES_FAIL); > } > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > For reference, the program's code is here: > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?ref_type=3Dhe= ads > > The library code, which is what's responsible for calling the > filesystem extended attribute related syscalls is here: > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/hardened/curre= nt/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > From the rights(4) manual page, I'm instructed all I need are to apply > those capabilities to that file descriptor: > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > So I'm a bit unsure if I'm doing something wrong. > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc What error code does it fail with? If it's ENOTCAPABLE, then I suggest using dtrace to find the reason why it fails. Do something like this: dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $target/ {trace(".");}' -c ./my_application That will print the name of every non-inlined kernel function that returns ENOTCAPABLE during your process. But it will also print the names of any other kernel functions that return an integer value of 93. From there, guess which function is the real source of the error. Then you can do dtrace -i 'fbt:kernel:some_function:return /arg1 =3D=3D 93 && pid =3D=3D $target/ {stack();}' -c ./myapplication to get more information. -Alan From nobody Sat Mar 23 00:56:10 2024 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 4V1gk919LQz5FnXw for ; Sat, 23 Mar 2024 00:56:17 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V1gk86Nq6z4fdv for ; Sat, 23 Mar 2024 00:56:16 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-xd2a.google.com with SMTP id ca18e2360f4ac-7d03a6a11a2so27762039f.2 for ; Fri, 22 Mar 2024 17:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1711155375; x=1711760175; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7SIiqkxfxYgzBs4ZkuDYLH0hFivmQEbLbWaI++r3G4Y=; b=FKM0t9piHEECJDRS1k2+vs8tD5j+n8c7nL0bY8+amexaZdQc/Zp9FONKRCdsVs3VHB uKv0PHY+Lc2CPyNnqgFGufkHEcGX90/RrT5y+L71S+kpzG/oX8rIcv0gZCGC/tQjxv+U qrBQ0aGK4DRUCHpAdMuAumSr5kvMQfUbHaYGnvK2F/lHZqq/uU5o7vjhA6cv0n4jSCg9 B+xFZru2wxgMqJUbSvMGOS9cIldxh7eXaNeZ/O3wbewVUQZfQgHhvbaUyCiupO2FOAgN R+QlCaA9NplIgIxOGvgZhiyRqa+jZaPQCF+OBYha/Iibo0y1ltSxrOheXXcL/vC2YnHb 7REQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711155375; x=1711760175; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7SIiqkxfxYgzBs4ZkuDYLH0hFivmQEbLbWaI++r3G4Y=; b=Gbsao574B00L4KLuOKXftXRQt++DfPfF542NEeceJBspp2n89DdVAdiRwYuWZq7BQJ BbY+qdcpF+wcDEr/gXqtpVSuhG86bvsWikoHy7NQbBUSB6czZ4cjBQcUrQt6UGBkGmk2 JiIr6l4BY0UlqDZ8m4sk4upOedN77Fsssl16vb6DQ3P2cElhk5X7BmKqp8p9wowp3jBY S+nglmZHjac7glDGHTaR7YDGPG3htAZ42C1jnm8AUt9d/sY8fpELgju9s8oolzZ29WeR C7/WMvT2pdYkHJpyjxR2PhoESw4e+p+Lq33bdmqZz7YkWIqLFXew2uYUvaNjs9BrOtbF FGOg== X-Gm-Message-State: AOJu0Yw0Hd4F2uaLB3l9Zm9oQqDqM5tq/rnjfmlL77utVvRPF7VwtIgw qY/n2OjtC5KktBkoIY6zvVaiRe38Hm+x8bb1Wkq03OXNhrs186k6NU47mJ5sZgc= X-Google-Smtp-Source: AGHT+IHvyCIl7s7iOR4X5tGWYyG/OzDPfVUDSEcYStZmKSGbCIAwgtV7HgOmrIds9H0uo34H9ATBIA== X-Received: by 2002:a5d:9b94:0:b0:7cc:ca7:c653 with SMTP id r20-20020a5d9b94000000b007cc0ca7c653mr1026073iom.21.1711155371441; Fri, 22 Mar 2024 17:56:11 -0700 (PDT) Received: from mutt-hbsd (174-24-72-211.clsp.qwest.net. [174.24.72.211]) by smtp.gmail.com with ESMTPSA id o18-20020a6b5a12000000b007d032b05766sm604574iob.36.2024.03.22.17.56.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 17:56:10 -0700 (PDT) Date: Sat, 23 Mar 2024 00:56:10 +0000 From: Shawn Webb To: Alan Somers Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem extended attributes and Capsicum Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hyz62y55337uhzt7" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V1gk86Nq6z4fdv --hyz62y55337uhzt7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > > > Hey all, > > > > I'm writing an application in which I hope to enable Capsicum. I'm > > experiencing an issue whereby extattr_get_fd fails with a file > > descriptor that has all the extended attribute capabilities enabled > > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > > CAP_EXTATTR_SET). > > > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells me that > > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > > > So I'm a bit puzzled as to why my call to extattr_get_fd(2) is > > failing. Am I doing something wrong or are filesystem extended > > attributes not supported in a Capabilities-enabled process? > > > > Here's how I'm creating the file descriptor (before calling > > cap_enter(2)): > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > static int > > open_file(const char *path) > > { > > cap_rights_t rights; > > int fd; > > > > fd =3D open(path, O_PATH | O_CLOEXEC); > > if (fd =3D=3D -1) { > > return (-1); > > } > > > > memset(&rights, 0, sizeof(rights)); > > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, > > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > > cap_rights_limit(fd, &rights); > > > > return (fd); > > } > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > Eventually, after calling cap_enter(2), the following code is called: > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME_ENABLED, = NULL, 0); > > if (sz <=3D 0) { > > if (errno =3D=3D ENOATTR) { > > /* > > * This is okay, it just means that nothing has = been set. > > * No error condition here. > > */ > > return (RES_SUCCESS); > > } > > return (RES_FAIL); > > } > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > For reference, the program's code is here: > > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?ref_type=3D= heads > > > > The library code, which is what's responsible for calling the > > filesystem extended attribute related syscalls is here: > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/hardened/cur= rent/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > > > From the rights(4) manual page, I'm instructed all I need are to apply > > those capabilities to that file descriptor: > > > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > > > So I'm a bit unsure if I'm doing something wrong. > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb= /03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc >=20 > What error code does it fail with? If it's ENOTCAPABLE, then I > suggest using dtrace to find the reason why it fails. Do something > like this: >=20 > dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $target/ > {trace(".");}' -c ./my_application >=20 > That will print the name of every non-inlined kernel function that > returns ENOTCAPABLE during your process. But it will also print the > names of any other kernel functions that return an integer value of > 93. From there, guess which function is the real source of the error. > Then you can do DTrace is unavailable on this particular system. It does indeed fail with ENOTCAPABLE. I have the kern.trap_enotcap sysctl set to 1 so that I can know at exactly what point we're failing, and it's indeed at extattr_get_fd. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --hyz62y55337uhzt7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmX+KKEACgkQ/y5nonf4 4fq64Q/6AkaAYz9Vo1Ld32z0VlRPoBeLuIY6KFF/5wc0tWbGSD6k8Q15u1RIuplp MM/gTX6QC9fpD7FR9ywasGBGBUtzGDnOtOvyjtJkmSFR9fc6umhn7kpxPLaxzHlF 65bFRD/+b37ePnoB/LOcOduPN9a9XFMhJiIte/UWJPFlYCDSTTkD9wkZsraxAFGS NGj0LfmgpD2DLVXckqoXRxuyZ0xqOpJBxUzfT+a+A5s0/FLLzJ1odcRouqm8jYI2 HjR9Jdnr8MPM2VAIrY8ug2Bs4mYmrdhjfPSXpd/+MiP3qwa8gNzKZUMvwSgZsNyg otmtR5EkJRA9UJ0kwWBe75MWMCOBKlE8liZ6sfwyaMp+rK1A6iVpp0sDqWzgifHG P+k9aBTtZwAgZIm/uiZkTmwrJ5vbnhd6OdFZyYYut9+F3cOTPHukqF+sGSpPz6/6 fzJHGpQFtTKE6WCxQLnPyzmsycB7zY2NxmUASNzR1N4v5WoZV5n6vgPxho0F6DMb 4Z82m7gu+pe4/E9XIGV9rXEd02aY84tBuKAsw7Z4QM+DsNmPuiyN82xIi0muG0Sv zn+3bA8/b8AU9KJeV+qDw2U/DXVk0fEDQNOgiURc0MEpqvRAakNkkFM28OrrHsaC HYsTcsMuoF6JRmeDEKrJsaBV2NgBuUjsuACkoQNCfU/xpYA4wnM= =0WA5 -----END PGP SIGNATURE----- --hyz62y55337uhzt7-- From nobody Sat Mar 23 02:07:17 2024 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 4V1jJK75WSz5FvxV for ; Sat, 23 Mar 2024 02:07:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V1jJK5DTnz4nk4 for ; Sat, 23 Mar 2024 02:07:29 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-f54.google.com with SMTP id a1e0cc1a2514c-7e046990b6aso1164096241.1 for ; Fri, 22 Mar 2024 19:07:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711159649; x=1711764449; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/ESsYLClGuGUl4zsMMdQTHx35z1rReZre65BKj8DpgY=; b=YdN9LjoCt4FNzXMUz05UZEZTxoQy2bcB4UgdYMdmm/dscQvf8Ylu8vSZAf/3nAiO5e hZiAoCRdlIBE5pmEAFkezAjFn+EjwWoXUStkLj9MmPXyqqI8GimPGQszwOtekIIkbrcI /FZYXE+HMZM4G2dUWSP49adS5oIaKxd5RwQpbknPZvtA3+uGofFTiXbCTWg/1nyzw+/n +2FhMn5nFc422SJtconU1EznItI19d9k9j5s2VWSEpFpN8ivxSdEwh73AKzJrZ9MT53E AmiNyEGHdhYHxaXuMycgHtBIMyXJiafv2tnI7SIEh7aklyK8N4bpsRtYeITsgS7Cz6dE KUkA== X-Gm-Message-State: AOJu0Yzx6DOzy/Np+ALjy93a+u/piIQ90MuYhFUgkvYECT07ZxS39n8E 8gw8DbK+U7OBOaYeYKUNM50nL8FlLu+SapHFRatUeDsQK2eSb0seGudFde38kmsAALkph6l9I2o 3T86NklDaJ6yrfssZ6SMztAUgNvQ= X-Google-Smtp-Source: AGHT+IHxwMw2CEPVPmvD//yloN9HZVW3wsWg6L1YLWDO+7MVfdjUvpBFgsM2V/TUBPHyBUu2o5KF9wOoz5/ccqA1QJY= X-Received: by 2002:a05:6122:32c7:b0:4d4:3fc:2869 with SMTP id ck7-20020a05612232c700b004d403fc2869mr1465338vkb.15.1711159648708; Fri, 22 Mar 2024 19:07:28 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Fri, 22 Mar 2024 20:07:17 -0600 Message-ID: Subject: Re: Filesystem extended attributes and Capsicum To: Shawn Webb Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4V1jJK5DTnz4nk4 On Fri, Mar 22, 2024 at 6:56=E2=80=AFPM Shawn Webb wrote: > > On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > > On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > > > > > Hey all, > > > > > > I'm writing an application in which I hope to enable Capsicum. I'm > > > experiencing an issue whereby extattr_get_fd fails with a file > > > descriptor that has all the extended attribute capabilities enabled > > > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > > > CAP_EXTATTR_SET). > > > > > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells me that > > > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > > > > > So I'm a bit puzzled as to why my call to extattr_get_fd(2) is > > > failing. Am I doing something wrong or are filesystem extended > > > attributes not supported in a Capabilities-enabled process? > > > > > > Here's how I'm creating the file descriptor (before calling > > > cap_enter(2)): > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > static int > > > open_file(const char *path) > > > { > > > cap_rights_t rights; > > > int fd; > > > > > > fd =3D open(path, O_PATH | O_CLOEXEC); > > > if (fd =3D=3D -1) { > > > return (-1); > > > } > > > > > > memset(&rights, 0, sizeof(rights)); > > > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, > > > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > > > cap_rights_limit(fd, &rights); > > > > > > return (fd); > > > } > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > Eventually, after calling cap_enter(2), the following code is called: > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > > > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME_ENABLED= , NULL, 0); > > > if (sz <=3D 0) { > > > if (errno =3D=3D ENOATTR) { > > > /* > > > * This is okay, it just means that nothing ha= s been set. > > > * No error condition here. > > > */ > > > return (RES_SUCCESS); > > > } > > > return (RES_FAIL); > > > } > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > For reference, the program's code is here: > > > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?ref_type= =3Dheads > > > > > > The library code, which is what's responsible for calling the > > > filesystem extended attribute related syscalls is here: > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/hardened/c= urrent/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > > > > > From the rights(4) manual page, I'm instructed all I need are to appl= y > > > those capabilities to that file descriptor: > > > > > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > > > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > > > > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > > > > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > > > > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > > > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > > > > > So I'm a bit unsure if I'm doing something wrong. > > > > > > Thanks, > > > > > > -- > > > Shawn Webb > > > Cofounder / Security Engineer > > > HardenedBSD > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_We= bb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > What error code does it fail with? If it's ENOTCAPABLE, then I > > suggest using dtrace to find the reason why it fails. Do something > > like this: > > > > dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $target/ > > {trace(".");}' -c ./my_application > > > > That will print the name of every non-inlined kernel function that > > returns ENOTCAPABLE during your process. But it will also print the > > names of any other kernel functions that return an integer value of > > 93. From there, guess which function is the real source of the error. > > Then you can do > > DTrace is unavailable on this particular system. > > It does indeed fail with ENOTCAPABLE. I have the kern.trap_enotcap sysctl > set to 1 so that I can know at exactly what point we're failing, and > it's indeed at extattr_get_fd. > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc Without dtrace, you've got your work cut out for you. I suggest simply adding all capabilities, verifying that extattr_get_fd works, and then removing capabilities until it fails. Or, run your program on vanilla FreeBSD with dtrace. From nobody Sat Mar 23 03:52:00 2024 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 4V1lcz4q0tz5G609 for ; Sat, 23 Mar 2024 03:52:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V1lcz2cdNz41V0 for ; Sat, 23 Mar 2024 03:52:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-36699481c87so9963555ab.3 for ; Fri, 22 Mar 2024 20:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1711165922; x=1711770722; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lmONmFEWleASaytPb9T/QBlEJcoOdXQrvsMgJg69yTs=; b=coQku3hi2ga/f42xcQ27KIi3/L0jkO8407gyo7lmQL1DHXQCBGq6ZcuTWQ22bx+9u5 NfynQimtrtb/XdVaO3dfs3pPSuH0oz0eMRltsJDr3vjswpe/orPOhXhyKW2l8Li0zD5K q5UzwosEGjUXThzuJRaNsBIveaCqgmLkQL54xr5mwFutklGFchNtDVl4P5eoAdQG8Aux 5d+pEIEpYHXm/N7hgdikPTSWY01zmVWsdMvpQxOIWcM9LssF4zS+Bl0qOWILjwQTNKm+ pxVPqwK6SxNKZ2Bm/Tms0eJwcVDaj6MKWzlS2a5SzS3evABcq0nqnlitNGGnLsBbntto w8xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711165922; x=1711770722; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lmONmFEWleASaytPb9T/QBlEJcoOdXQrvsMgJg69yTs=; b=Zg5nDkH5bhI5k3Ugu+OCpSXhVAOha1nd68lCaGFAvXI2I+aQfloYkF9Qh/HGOa7DwE 4t1dAMVRjY/8OhJfiZzyXzjv0z8HBiTAZWeHYQdY7bzsmquaubsEWjbb8tByYsheJ4qo /j8FyUgC9a6yEIkZxQf97C3k+7vUl8JG+aqdulXqfhFzK9HuBhN7pAhJ4bU0W0sc1078 RH2AzU6f+WHRO4VBS8CgS4QIpjlaqLRfivYPN2b4Owfp00dseWQwbvmBFwORzthOTe3Z 0N9BRE0HTi9ymloW2/zWhfgVQYeu7WJSlOIl7gnneV+XiM24LOWq7JlRVrkEyk5Ol6KS oIYg== X-Gm-Message-State: AOJu0YwbrTyfNa0IUxawzRaeGmuMmbYebV7BeX0J7ZH3A434pGb8Sk9P RswUAZTbUGmaUeip4uHXXqLjVSrBZs+GRyZHhsrq8MEPhrRcjBEURey0TOp4BiI= X-Google-Smtp-Source: AGHT+IFHiLtn4i0Q3aF7ApxJBcezPF69reqIA/sc6fvuQI+sVfFiyeIwRwB/z9AogWmJ2maWKeNyGQ== X-Received: by 2002:a92:d851:0:b0:368:6b4f:3390 with SMTP id h17-20020a92d851000000b003686b4f3390mr1334423ilq.22.1711165921633; Fri, 22 Mar 2024 20:52:01 -0700 (PDT) Received: from mutt-hbsd (174-24-72-211.clsp.qwest.net. [174.24.72.211]) by smtp.gmail.com with ESMTPSA id q13-20020a92050d000000b003685b26d4afsm970557ile.23.2024.03.22.20.52.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 20:52:00 -0700 (PDT) Date: Sat, 23 Mar 2024 03:52:00 +0000 From: Shawn Webb To: Alan Somers Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem extended attributes and Capsicum Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u5ejocsibznm2xjw" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V1lcz2cdNz41V0 --u5ejocsibznm2xjw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2024 at 08:07:17PM -0600, Alan Somers wrote: > On Fri, Mar 22, 2024 at 6:56=E2=80=AFPM Shawn Webb wrote: > > > > On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > > > On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > > > > > > > Hey all, > > > > > > > > I'm writing an application in which I hope to enable Capsicum. I'm > > > > experiencing an issue whereby extattr_get_fd fails with a file > > > > descriptor that has all the extended attribute capabilities enabled > > > > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > > > > CAP_EXTATTR_SET). > > > > > > > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells me that > > > > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > > > > > > > So I'm a bit puzzled as to why my call to extattr_get_fd(2) is > > > > failing. Am I doing something wrong or are filesystem extended > > > > attributes not supported in a Capabilities-enabled process? > > > > > > > > Here's how I'm creating the file descriptor (before calling > > > > cap_enter(2)): > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > static int > > > > open_file(const char *path) > > > > { > > > > cap_rights_t rights; > > > > int fd; > > > > > > > > fd =3D open(path, O_PATH | O_CLOEXEC); > > > > if (fd =3D=3D -1) { > > > > return (-1); > > > > } > > > > > > > > memset(&rights, 0, sizeof(rights)); > > > > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTATTR_GE= T, > > > > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > > > > cap_rights_limit(fd, &rights); > > > > > > > > return (fd); > > > > } > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > Eventually, after calling cap_enter(2), the following code is calle= d: > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > > > > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME_ENABL= ED, NULL, 0); > > > > if (sz <=3D 0) { > > > > if (errno =3D=3D ENOATTR) { > > > > /* > > > > * This is okay, it just means that nothing = has been set. > > > > * No error condition here. > > > > */ > > > > return (RES_SUCCESS); > > > > } > > > > return (RES_FAIL); > > > > } > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > For reference, the program's code is here: > > > > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?ref_typ= e=3Dheads > > > > > > > > The library code, which is what's responsible for calling the > > > > filesystem extended attribute related syscalls is here: > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/hardened= /current/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > > > > > > > From the rights(4) manual page, I'm instructed all I need are to ap= ply > > > > those capabilities to that file descriptor: > > > > > > > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > > > > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > > > > > > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > > > > > > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > > > > > > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > > > > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > > > > > > > So I'm a bit unsure if I'm doing something wrong. > > > > > > > > Thanks, > > > > > > > > -- > > > > Shawn Webb > > > > Cofounder / Security Engineer > > > > HardenedBSD > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_= Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > What error code does it fail with? If it's ENOTCAPABLE, then I > > > suggest using dtrace to find the reason why it fails. Do something > > > like this: > > > > > > dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $target/ > > > {trace(".");}' -c ./my_application > > > > > > That will print the name of every non-inlined kernel function that > > > returns ENOTCAPABLE during your process. But it will also print the > > > names of any other kernel functions that return an integer value of > > > 93. From there, guess which function is the real source of the error. > > > Then you can do > > > > DTrace is unavailable on this particular system. > > > > It does indeed fail with ENOTCAPABLE. I have the kern.trap_enotcap sysc= tl > > set to 1 so that I can know at exactly what point we're failing, and > > it's indeed at extattr_get_fd. > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb= /03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc >=20 > Without dtrace, you've got your work cut out for you. I suggest > simply adding all capabilities, verifying that extattr_get_fd works, > and then removing capabilities until it fails. Or, run your program > on vanilla FreeBSD with dtrace. HardenedBSD doesn't have any modifications that would affect Capsicum in this manner. Regardless, I reproduced the problem successfully on FreeBSD 14.0-RELEASE without any code changes. I tried running your DTrace script on FreeBSD 14.0-RELEASE and got this output: =3D=3D=3D=3D BEGIN OUTPUT =3D=3D=3D=3D $ sudo dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $target/= {trace(".");}' -c "obj/hbsdctrl pax list /bin/ls" dtrace: description 'fbt:kernel::return ' matched 31396 probes aslr: sysdef mprotect: sysdef pageexec: sysdef segvguard: sysdef dtrace: pid 29270 has exited CPU ID FUNCTION:NAME 3 47780 foffset_unlock_uio:return . = =20 3 50605 foffset_lock:return . = =20 3 47778 foffset_lock_uio:return . =3D=3D=3D=3D END OUTPUT =3D=3D=3D=3D But I'm still unsure what I'm missing, if anything. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --u5ejocsibznm2xjw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmX+UdMACgkQ/y5nonf4 4fqBBg//cDEqfDfoHbgVkLnnkph8Xkmj6K2gEq07BeJENv2YAQAatk1QfLhrpylj zbmfhpCazdQD2aTeaQP0wo4+qRD3cIWqRYsTfDt+800osCrRBBWeQxEzlMOIvEGe Ec+PT6MdvM5BjeCqBX8NPM+LQ8i0YLiOLiw0EY5esEisF8R89Z3vTC5Ulez/ErNg ZqIaMCqtuh2O+RM1iZRw97zDRGSmj4SoL47zTJ2op8CWj1HmoawGkOEJ0pkAs6YS HaQWfG3GGzrRJImuZyoACPTL8MVjRZDRZqewI0cwjmMTWGc5/EV29cUOAxowh7mY EQfawwWjcVPzkOqQP0rxOuVjpHEs8xVXYs6FivlenxVMH5EXSV/DUTzTxcymd3nM lQVZldsOPLfkLU+l4gakih69s5fDQZbc7Rroo6UTt8c6WKAzjGx/KNVxgqHqEZhg wbJ0mZoK96I9zQpQF+dri9faIAHui6VbLNHzVh30tSHlA3nwUg8w+2NVmyyMSeeF 8dxahXt2w4oxJAHeJlssJdgmSmKWZAei7e/7fktFsAPAKTRXtywpkj7e/+eV2JJX IYCya9etRgZfqT5KVXq8Bk7fbAFKLB46wnwqaZWOwWnclt1r16RRr4qJyqODxPUF WRysyl+7yBCNBQmwOW7kKC0DUh/E9pJekKkqjRh9VqxoFASfhpc= =tRsU -----END PGP SIGNATURE----- --u5ejocsibznm2xjw-- From nobody Sat Mar 23 13:58:37 2024 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 4V215712hqz5F266 for ; Sat, 23 Mar 2024 13:58:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V21556lpYz50wL; Sat, 23 Mar 2024 13:58:49 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-7e0f4106a8bso345241241.1; Sat, 23 Mar 2024 06:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711202329; x=1711807129; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=o2j5c4IEyJY6LexHgR2/c8h42TYS+TT3xDNYNAHGfKQ=; b=IysWFjUg5ggie95G1e08dQp9cwAdqR+wiFknkBa7B56Bx0N6WJ+l0hbVY0fXcT2Ltn udGmlZucRRfQZnDRhMVoR/0ggya2JeK4CW50fxuzDlaqNn5fpzx7o3mhEdp3DHBHDV7A HbytWEHnnimOMTLM9KuNTorjCfCov4xJ9Lj+uQ1sCu/Ou4hrTkOLsnKLGcBw1NzQI8UX 4yj2BCtspsgj+TZjWIaFV7Ern7i9faTNnkrJN+7PlphovpSop036HMFGpO2oBV/0TIW5 k3dJrUdwHl90QjV3VKVsvnt7mjbnQJTQzn3ULw9DoGWGm26DbD29+KMq5ltLU76F6Duy 0XZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711202329; x=1711807129; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=o2j5c4IEyJY6LexHgR2/c8h42TYS+TT3xDNYNAHGfKQ=; b=RfLOICLEM1np6NchvyKcwntWmxqVemYqk+mSYiGXVUrLrMkoLcwvf+OYeajv2Yu1l/ 7SYvPyOrhzEVh2Q9R+HxFtlmfFqNUMnmWlMLOvyk7pO0VGSfBOxlEZRtQgitwVBHF6EH Z9oE5SmDSpRa0aYuT2o1rVidkSe2fVdKwvdHfv/jHp+czDdIBWq0o8Z01wNMvzPvDt82 Z3V7XzJpZQ7Dbx6+L8BrU22GnzZ7VKGIYYGnkgL02GGNexjsLkJTUHekxBrpybDYIbzF V0AOg6sj44drSzTGNQvsU7MYGJtGyJvjMTasM/dvny4SD6g4q2iyZRfw2x8uT18CoH7Z VBXg== X-Forwarded-Encrypted: i=1; AJvYcCWK2TFPlA37Bdpnv++STTul7pvzca+pUyoKPXR1cmMg4fENxJijfo2k1GQZPZNAPlN8pVv06eoKBSx2rSM4+BmIi7g5o8flBQj+2JY= X-Gm-Message-State: AOJu0Yy5mIbX7aI84pIM5SnI3y9+JQlcI1qDTMIxz58TV0XkUV0navks wrgmPluEON5iX79btO0GbdWo2+2goRQMuHy1O9U/h5bBWEqXS94LiuckXPMr4RQDmKNnaCmcRzl cpNZ5QEIXAKDxW3Q6hSjmx3f2V4TcOz32BLw= X-Google-Smtp-Source: AGHT+IHsC/EB9WPnK2NbVbNdaXcQpc+jfv/VEijStQka8a/sbzCHNNYezF+PcozBBR+SGpF6izMJ9BWU++9uRJLC2lk= X-Received: by 2002:a67:ec45:0:b0:476:d40e:2e27 with SMTP id z5-20020a67ec45000000b00476d40e2e27mr1955661vso.30.1711202329177; Sat, 23 Mar 2024 06:58:49 -0700 (PDT) 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 References: In-Reply-To: From: alan somers Date: Sat, 23 Mar 2024 07:58:37 -0600 Message-ID: Subject: Re: Filesystem extended attributes and Capsicum To: Shawn Webb Cc: Alan Somers , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V21556lpYz50wL On Fri, Mar 22, 2024 at 9:52=E2=80=AFPM Shawn Webb wrote: > > On Fri, Mar 22, 2024 at 08:07:17PM -0600, Alan Somers wrote: > > On Fri, Mar 22, 2024 at 6:56=E2=80=AFPM Shawn Webb wrote: > > > > > > On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > > > > On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > Hey all, > > > > > > > > > > I'm writing an application in which I hope to enable Capsicum. I'= m > > > > > experiencing an issue whereby extattr_get_fd fails with a file > > > > > descriptor that has all the extended attribute capabilities enabl= ed > > > > > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > > > > > CAP_EXTATTR_SET). > > > > > > > > > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells me th= at > > > > > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > > > > > > > > > So I'm a bit puzzled as to why my call to extattr_get_fd(2) is > > > > > failing. Am I doing something wrong or are filesystem extended > > > > > attributes not supported in a Capabilities-enabled process? > > > > > > > > > > Here's how I'm creating the file descriptor (before calling > > > > > cap_enter(2)): > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > static int > > > > > open_file(const char *path) > > > > > { > > > > > cap_rights_t rights; > > > > > int fd; > > > > > > > > > > fd =3D open(path, O_PATH | O_CLOEXEC); > > > > > if (fd =3D=3D -1) { > > > > > return (-1); > > > > > } > > > > > > > > > > memset(&rights, 0, sizeof(rights)); > > > > > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTATTR_= GET, > > > > > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > > > > > cap_rights_limit(fd, &rights); > > > > > > > > > > return (fd); > > > > > } > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > Eventually, after calling cap_enter(2), the following code is cal= led: > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > > > > > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME_ENA= BLED, NULL, 0); > > > > > if (sz <=3D 0) { > > > > > if (errno =3D=3D ENOATTR) { > > > > > /* > > > > > * This is okay, it just means that nothin= g has been set. > > > > > * No error condition here. > > > > > */ > > > > > return (RES_SUCCESS); > > > > > } > > > > > return (RES_FAIL); > > > > > } > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > For reference, the program's code is here: > > > > > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?ref_t= ype=3Dheads > > > > > > > > > > The library code, which is what's responsible for calling the > > > > > filesystem extended attribute related syscalls is here: > > > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/harden= ed/current/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > > > > > > > > > From the rights(4) manual page, I'm instructed all I need are to = apply > > > > > those capabilities to that file descriptor: > > > > > > > > > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > > > > > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > > > > > > > > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > > > > > > > > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > > > > > > > > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > > > > > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > > > > > > > > > So I'm a bit unsure if I'm doing something wrong. > > > > > > > > > > Thanks, > > > > > > > > > > -- > > > > > Shawn Webb > > > > > Cofounder / Security Engineer > > > > > HardenedBSD > > > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shaw= n_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > > > What error code does it fail with? If it's ENOTCAPABLE, then I > > > > suggest using dtrace to find the reason why it fails. Do something > > > > like this: > > > > > > > > dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $target= / > > > > {trace(".");}' -c ./my_application > > > > > > > > That will print the name of every non-inlined kernel function that > > > > returns ENOTCAPABLE during your process. But it will also print th= e > > > > names of any other kernel functions that return an integer value of > > > > 93. From there, guess which function is the real source of the err= or. > > > > Then you can do > > > > > > DTrace is unavailable on this particular system. > > > > > > It does indeed fail with ENOTCAPABLE. I have the kern.trap_enotcap sy= sctl > > > set to 1 so that I can know at exactly what point we're failing, and > > > it's indeed at extattr_get_fd. > > > > > > Thanks, > > > > > > -- > > > Shawn Webb > > > Cofounder / Security Engineer > > > HardenedBSD > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_We= bb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > Without dtrace, you've got your work cut out for you. I suggest > > simply adding all capabilities, verifying that extattr_get_fd works, > > and then removing capabilities until it fails. Or, run your program > > on vanilla FreeBSD with dtrace. > > HardenedBSD doesn't have any modifications that would affect Capsicum > in this manner. Regardless, I reproduced the problem successfully on > FreeBSD 14.0-RELEASE without any code changes. I tried running your > DTrace script on FreeBSD 14.0-RELEASE and got this output: > > =3D=3D=3D=3D BEGIN OUTPUT =3D=3D=3D=3D > $ sudo dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $targe= t/ {trace(".");}' -c "obj/hbsdctrl pax list /bin/ls" > dtrace: description 'fbt:kernel::return ' matched 31396 probes > aslr: sysdef > mprotect: sysdef > pageexec: sysdef > segvguard: sysdef > dtrace: pid 29270 has exited > CPU ID FUNCTION:NAME > 3 47780 foffset_unlock_uio:return . > 3 50605 foffset_lock:return . > 3 47778 foffset_lock_uio:return . > =3D=3D=3D=3D END OUTPUT =3D=3D=3D=3D > > But I'm still unsure what I'm missing, if anything. That's red herring. Those functions return void, but dtrace doesn't know it. So the "93" is just register garbage. I also notice that kern_extattr_get_fd isn't listed. Are you sure that your program is really failing with ENOTCAPABLE? You can also try running it with ktrace. kdump will show you exactly what capabilities you limited the file descriptor to. That can help you verify if you applied the limits correctly. -Alan From nobody Sat Mar 23 14:25:26 2024 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 4V21gv4M1Pz5F4g0 for ; Sat, 23 Mar 2024 14:25:31 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V21gv2chBz54k7 for ; Sat, 23 Mar 2024 14:25:31 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x12d.google.com with SMTP id e9e14a558f8ab-368713f2f23so6789915ab.3 for ; Sat, 23 Mar 2024 07:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1711203929; x=1711808729; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xpkJayEPkJ9MS1ukzbVt7qy2QtdMm41loJxn3kOiLEs=; b=eVTkRtQH9cr+bHm7+5iKcgPymOwdZ+5x0V3j15/d1zp7JS9FA/k4/MP7k1ggEfz61/ 1kIEt2+3qMesmEPnOjpwcQUOsFnE58C7gORK6mVWXD1lQ/7bkB9WZ3TFNzwnI335M4Ih 8GjBayV212PZg7UstQWXjeIliaSOGwEBo+E1GFgwzYZOFWGfS3f0ggzJbMzYFHPauyk+ ddXHZFc8iMaKO7UECfoTlAOiOdskH/hjk5pthWlifJyw5QFgzt0fU1hXdlPjOKROEpiD B1y8RiyG+nxmM1KQ6hRUmGwMlcCqTkAm5loAzQEY4t2xJRRV9gJJQrMf9t/ATEn69yI0 R67A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711203929; x=1711808729; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xpkJayEPkJ9MS1ukzbVt7qy2QtdMm41loJxn3kOiLEs=; b=Iymj3SJ54xUQr1qg2hyZhc8sP2uVewRSIh7te+iVxGTpwPC0UL2Kn8fnQBz0Tu4aN5 kbSZqzTQVYPkmFYPMT/ukubFEYN3rLUBpOWjLdr00gSm6JCGSEfc2RqdXmWeZEIj2p4v 4/SokTl81o3c8yS4QPms52QSpdL6f6HSWwpyTZGC91YtpUwiiLxKckTvO/a9Ry1fOBEs rGfefRyLqciWnvQfvnU9M0Pdc+xfDLPQaW9ZNZkeLLaVT9+9FaHQ9Q+AYjTsuRm4qpuM 0A9lLaYu8z81L3faq1ycwBosfbsV7iU3zAvShXWySGZ92K59JMlttVeDTEh3722Vrz/Z xt6Q== X-Forwarded-Encrypted: i=1; AJvYcCVeqi67JZeD/r6tkHA9BYfHsQA03W6rYCrFz1qOCmD0wnGToVIu7Xz0YnPURqLb/9DRzKSaaGunCYgyPG87hNOahyTUA+O3rwjOTow= X-Gm-Message-State: AOJu0YzenjXl0/MNZoFGq15GIap6OuwQ0iPP9ZybGouTRwGEkfxAlFBF SQpUcML9cng3VECfPiHEyRiD2FpRYRQYInhdlpaEP7UYHQXMGVpkjibIg0rf0pc= X-Google-Smtp-Source: AGHT+IE1aP+rGqJ8AVZldw0VyOfPGX1VJxUc1VuCxTdYfDjWoxJEN5QrScv9iaNarEpfyQ1/abuzDQ== X-Received: by 2002:a92:b707:0:b0:365:c6ae:c40e with SMTP id k7-20020a92b707000000b00365c6aec40emr2372143ili.0.1711203929490; Sat, 23 Mar 2024 07:25:29 -0700 (PDT) Received: from mutt-hbsd (174-24-72-211.clsp.qwest.net. [174.24.72.211]) by smtp.gmail.com with ESMTPSA id z11-20020a92da0b000000b00366970137d7sm1222566ilm.16.2024.03.23.07.25.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Mar 2024 07:25:27 -0700 (PDT) Date: Sat, 23 Mar 2024 14:25:26 +0000 From: Shawn Webb To: alan somers Cc: Alan Somers , freebsd-hackers@freebsd.org Subject: Re: Filesystem extended attributes and Capsicum Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u4vp3o3k5n256pfh" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V21gv2chBz54k7 --u4vp3o3k5n256pfh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 23, 2024 at 07:58:37AM -0600, alan somers wrote: > On Fri, Mar 22, 2024 at 9:52=E2=80=AFPM Shawn Webb wrote: > > > > On Fri, Mar 22, 2024 at 08:07:17PM -0600, Alan Somers wrote: > > > On Fri, Mar 22, 2024 at 6:56=E2=80=AFPM Shawn Webb wrote: > > > > > > > > On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > > > > > On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > Hey all, > > > > > > > > > > > > I'm writing an application in which I hope to enable Capsicum. = I'm > > > > > > experiencing an issue whereby extattr_get_fd fails with a file > > > > > > descriptor that has all the extended attribute capabilities ena= bled > > > > > > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > > > > > > CAP_EXTATTR_SET). > > > > > > > > > > > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells me = that > > > > > > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > > > > > > > > > > > So I'm a bit puzzled as to why my call to extattr_get_fd(2) is > > > > > > failing. Am I doing something wrong or are filesystem extended > > > > > > attributes not supported in a Capabilities-enabled process? > > > > > > > > > > > > Here's how I'm creating the file descriptor (before calling > > > > > > cap_enter(2)): > > > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > > static int > > > > > > open_file(const char *path) > > > > > > { > > > > > > cap_rights_t rights; > > > > > > int fd; > > > > > > > > > > > > fd =3D open(path, O_PATH | O_CLOEXEC); > > > > > > if (fd =3D=3D -1) { > > > > > > return (-1); > > > > > > } > > > > > > > > > > > > memset(&rights, 0, sizeof(rights)); > > > > > > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTATT= R_GET, > > > > > > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > > > > > > cap_rights_limit(fd, &rights); > > > > > > > > > > > > return (fd); > > > > > > } > > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > > > Eventually, after calling cap_enter(2), the following code is c= alled: > > > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > > > > > > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME_E= NABLED, NULL, 0); > > > > > > if (sz <=3D 0) { > > > > > > if (errno =3D=3D ENOATTR) { > > > > > > /* > > > > > > * This is okay, it just means that noth= ing has been set. > > > > > > * No error condition here. > > > > > > */ > > > > > > return (RES_SUCCESS); > > > > > > } > > > > > > return (RES_FAIL); > > > > > > } > > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > > > For reference, the program's code is here: > > > > > > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?ref= _type=3Dheads > > > > > > > > > > > > The library code, which is what's responsible for calling the > > > > > > filesystem extended attribute related syscalls is here: > > > > > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/hard= ened/current/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > > > > > > > > > > > From the rights(4) manual page, I'm instructed all I need are t= o apply > > > > > > those capabilities to that file descriptor: > > > > > > > > > > > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > > > > > > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > > > > > > > > > > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > > > > > > > > > > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > > > > > > > > > > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > > > > > > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > > > > > > > > > > > So I'm a bit unsure if I'm doing something wrong. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -- > > > > > > Shawn Webb > > > > > > Cofounder / Security Engineer > > > > > > HardenedBSD > > > > > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Sh= awn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > > > > > What error code does it fail with? If it's ENOTCAPABLE, then I > > > > > suggest using dtrace to find the reason why it fails. Do somethi= ng > > > > > like this: > > > > > > > > > > dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $targ= et/ > > > > > {trace(".");}' -c ./my_application > > > > > > > > > > That will print the name of every non-inlined kernel function that > > > > > returns ENOTCAPABLE during your process. But it will also print = the > > > > > names of any other kernel functions that return an integer value = of > > > > > 93. From there, guess which function is the real source of the e= rror. > > > > > Then you can do > > > > > > > > DTrace is unavailable on this particular system. > > > > > > > > It does indeed fail with ENOTCAPABLE. I have the kern.trap_enotcap = sysctl > > > > set to 1 so that I can know at exactly what point we're failing, and > > > > it's indeed at extattr_get_fd. > > > > > > > > Thanks, > > > > > > > > -- > > > > Shawn Webb > > > > Cofounder / Security Engineer > > > > HardenedBSD > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_= Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > Without dtrace, you've got your work cut out for you. I suggest > > > simply adding all capabilities, verifying that extattr_get_fd works, > > > and then removing capabilities until it fails. Or, run your program > > > on vanilla FreeBSD with dtrace. > > > > HardenedBSD doesn't have any modifications that would affect Capsicum > > in this manner. Regardless, I reproduced the problem successfully on > > FreeBSD 14.0-RELEASE without any code changes. I tried running your > > DTrace script on FreeBSD 14.0-RELEASE and got this output: > > > > =3D=3D=3D=3D BEGIN OUTPUT =3D=3D=3D=3D > > $ sudo dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $tar= get/ {trace(".");}' -c "obj/hbsdctrl pax list /bin/ls" > > dtrace: description 'fbt:kernel::return ' matched 31396 probes > > aslr: sysdef > > mprotect: sysdef > > pageexec: sysdef > > segvguard: sysdef > > dtrace: pid 29270 has exited > > CPU ID FUNCTION:NAME > > 3 47780 foffset_unlock_uio:return . > > 3 50605 foffset_lock:return . > > 3 47778 foffset_lock_uio:return . > > =3D=3D=3D=3D END OUTPUT =3D=3D=3D=3D > > > > But I'm still unsure what I'm missing, if anything. >=20 > That's red herring. Those functions return void, but dtrace doesn't > know it. So the "93" is just register garbage. I also notice that > kern_extattr_get_fd isn't listed. Are you sure that your program is > really failing with ENOTCAPABLE? You can also try running it with > ktrace. kdump will show you exactly what capabilities you limited the > file descriptor to. That can help you verify if you applied the > limits correctly. I'm pretty sure it's failing with ENOTCAPABLE, since the kern.trap_enotcap sysctl logic is being hit at the point of the extattr_get_fd syscall. I'll see what I can do with ktrace. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --u4vp3o3k5n256pfh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmX+5lAACgkQ/y5nonf4 4fpq9hAAmwzpv035tVfyfs4o4XF4K2k2Q/1oVUA3gFOya0uk/XBifnNIvpbxtlJL iM/dSx36xrkdJylqNIycfQMlpOn0NJ4IUuVxvPNelptBYtHH7dltX1T8t9SkjkTR AVWKLBKSC+cxxFXJJIJ9iWBghWPHt2/ysLC9hiUS8mD5HVrc4tVK2GyxN4g2qALd KtZMMFgHjSdvd2069sosyuuz7prNYy01c56I2VBvAHj0ZRkS0q2Uwk0bTkLUTm61 Yg1weBC4GFVpHi5nOGAlVkR5mFyDhI3AeSeludLPumMp+PtVMzlD14V2mRldtMPW 8DN9bY8YhCTENpZ4EAZi8s5gva7562Ws19+1nU1hcSWMso6H8hLvq6qbTV0xRXDP nAowhN+TPK+v4ZczlmlhXiwiJwxMckObRBW5ROtWQiNCrpN4RafmNTHFZMayi3hK Wiq2r2rDM75pS5ef+hymQh/vJ5EpLfoVIkivwBtGCHSBkXQF4VFTxr6cbnQEfD6Z PaOkm0VkU+Yvib+HjyIccllKKhEe3BXiiwuXkJ7gyQk1yFdww9nolKUXHbz0uubj HnwfoMeSrUWqvYvxcTFqrWkycPtg8NagbQ1/0joQJvsP41JG7zZ2rVZRxnJS6dCs jtSy+CVwrBD2mvqbd/p58HLZeNkYOKLF8KsqP8VcjHjig0xvklI= =8tmf -----END PGP SIGNATURE----- --u4vp3o3k5n256pfh-- From nobody Sat Mar 23 14:54:22 2024 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 4V22KF6TY0z5F7p8 for ; Sat, 23 Mar 2024 14:54:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V22KF1y7yz5751 for ; Sat, 23 Mar 2024 14:54:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=BNaHfCtd; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d2d as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-7d03a66e895so24222139f.1 for ; Sat, 23 Mar 2024 07:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1711205663; x=1711810463; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Iuxkp6TsQqkG/KDwP0lMzayFAAtfvJDWmUAfig+6fqg=; b=BNaHfCtdX24I8aVT4Up6WmVg0TdbSlxp23F3zeZKVEse4xgpH788bTRNPYBK1YciZ8 P64fYMN21sSEev+W6TNxe1aWekIvsz9I3C+rR7/Z+slSP9lG9y9XA6m+Hg1nB4loY1EB zf7PwUVG4esR04S+yVlRu8nRhFjcCn//1ATzc23J7bEwqMyXTT2lE0cLdM6e6USZTv++ y4D6c1sX+poHskJpTo44vZM+u9ajCLRIjrD8MGKbDnqVZCEHngfM6a/2VZPS/lmS6AYs /iRWFHNyhaaJ25H95lFpyt6bGqcU+SXctEFYWGqKLhHw2aKFxZ1UJJFMDaDx0h90emm1 b4vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711205663; x=1711810463; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Iuxkp6TsQqkG/KDwP0lMzayFAAtfvJDWmUAfig+6fqg=; b=D0kNXmmoZmSDa8xjEniwPHg3NAZCB2r+OSa8waLX45dgQE1zisW4fxpG5yALsyrVa9 tl0lHBppPO5sxh/iscHbvIC0+AJSnMk8n/Tr7uNhDfVm56R5++G50gi/S8W1g9WeZmZM 8x1SyREuj6rA18g72Vvuf28MVNINFhFN8si7FBeB8SkBhCzmMZA0HyEp2wlZMSvef1jN Y8Nwoi6VXQGQfUU4tLN6juLsj3xbHnWEySpE8ECiG+f1GUeGEj0BAczTYtww9RDRL1m7 Tw6uCngMiLG7pzP60IWVuEf8R+LV9XGa5ArIVn7uebeWPTCsH8n/DPOazrLvk7UZw6sA gibA== X-Forwarded-Encrypted: i=1; AJvYcCVsO6jGc6Wirk7KsMYp80MbsBuszgL1CjP1P43pJgOF+leEh5J2CM6c7ktOUbhfJCQCVy5Qtru/6xiyTIQafTsTcuJ/FX0M1qoW2gI= X-Gm-Message-State: AOJu0YwgL4A2iMYaFJxf3lUHnc3wOhxUp/9lcB6d6mteZzhDDhTc0mkq yg2qSStSBR62BAXi40tFUxiI2fNr6j+mBo6nsvDy4z4cOJzL8I4x/qc8hwSEwiO4CJvzfwymot5 D X-Google-Smtp-Source: AGHT+IGHBH6TWBwyyzgYbbaYxBcyk2cRCjdl7djfaNm0OjQy0ZFl23G+qkOWhsqCU7IE6Fr6XqNdYg== X-Received: by 2002:a5d:8942:0:b0:7d0:2cfd:8dd2 with SMTP id b2-20020a5d8942000000b007d02cfd8dd2mr1264386iot.8.1711205663414; Sat, 23 Mar 2024 07:54:23 -0700 (PDT) Received: from mutt-hbsd (174-24-72-211.clsp.qwest.net. [174.24.72.211]) by smtp.gmail.com with ESMTPSA id b12-20020a6b670c000000b007cf191a8daesm1304367ioc.17.2024.03.23.07.54.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Mar 2024 07:54:22 -0700 (PDT) Date: Sat, 23 Mar 2024 14:54:22 +0000 From: Shawn Webb To: alan somers Cc: Alan Somers , freebsd-hackers@freebsd.org Subject: Re: Filesystem extended attributes and Capsicum Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zogso432rrk4m4bp" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2d:from] X-Rspamd-Queue-Id: 4V22KF1y7yz5751 --zogso432rrk4m4bp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 23, 2024 at 02:25:26PM +0000, Shawn Webb wrote: > On Sat, Mar 23, 2024 at 07:58:37AM -0600, alan somers wrote: > > On Fri, Mar 22, 2024 at 9:52=E2=80=AFPM Shawn Webb wrote: > > > > > > On Fri, Mar 22, 2024 at 08:07:17PM -0600, Alan Somers wrote: > > > > On Fri, Mar 22, 2024 at 6:56=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > > > > > > On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > Hey all, > > > > > > > > > > > > > > I'm writing an application in which I hope to enable Capsicum= =2E I'm > > > > > > > experiencing an issue whereby extattr_get_fd fails with a file > > > > > > > descriptor that has all the extended attribute capabilities e= nabled > > > > > > > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > > > > > > > CAP_EXTATTR_SET). > > > > > > > > > > > > > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells m= e that > > > > > > > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > > > > > > > > > > > > > So I'm a bit puzzled as to why my call to extattr_get_fd(2) is > > > > > > > failing. Am I doing something wrong or are filesystem extended > > > > > > > attributes not supported in a Capabilities-enabled process? > > > > > > > > > > > > > > Here's how I'm creating the file descriptor (before calling > > > > > > > cap_enter(2)): > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > > > static int > > > > > > > open_file(const char *path) > > > > > > > { > > > > > > > cap_rights_t rights; > > > > > > > int fd; > > > > > > > > > > > > > > fd =3D open(path, O_PATH | O_CLOEXEC); > > > > > > > if (fd =3D=3D -1) { > > > > > > > return (-1); > > > > > > > } > > > > > > > > > > > > > > memset(&rights, 0, sizeof(rights)); > > > > > > > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTA= TTR_GET, > > > > > > > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > > > > > > > cap_rights_limit(fd, &rights); > > > > > > > > > > > > > > return (fd); > > > > > > > } > > > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > > > > > Eventually, after calling cap_enter(2), the following code is= called: > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > > > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > > > > > > > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME= _ENABLED, NULL, 0); > > > > > > > if (sz <=3D 0) { > > > > > > > if (errno =3D=3D ENOATTR) { > > > > > > > /* > > > > > > > * This is okay, it just means that no= thing has been set. > > > > > > > * No error condition here. > > > > > > > */ > > > > > > > return (RES_SUCCESS); > > > > > > > } > > > > > > > return (RES_FAIL); > > > > > > > } > > > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > > > > > For reference, the program's code is here: > > > > > > > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?r= ef_type=3Dheads > > > > > > > > > > > > > > The library code, which is what's responsible for calling the > > > > > > > filesystem extended attribute related syscalls is here: > > > > > > > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/ha= rdened/current/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > > > > > > > > > > > > > From the rights(4) manual page, I'm instructed all I need are= to apply > > > > > > > those capabilities to that file descriptor: > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > > > > > > > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > > > > > > > > > > > > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > > > > > > > > > > > > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > > > > > > > > > > > > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > > > > > > > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > > > > > > > > > > > > > So I'm a bit unsure if I'm doing something wrong. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > -- > > > > > > > Shawn Webb > > > > > > > Cofounder / Security Engineer > > > > > > > HardenedBSD > > > > > > > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/= Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > > > > > > > What error code does it fail with? If it's ENOTCAPABLE, then I > > > > > > suggest using dtrace to find the reason why it fails. Do somet= hing > > > > > > like this: > > > > > > > > > > > > dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $ta= rget/ > > > > > > {trace(".");}' -c ./my_application > > > > > > > > > > > > That will print the name of every non-inlined kernel function t= hat > > > > > > returns ENOTCAPABLE during your process. But it will also prin= t the > > > > > > names of any other kernel functions that return an integer valu= e of > > > > > > 93. From there, guess which function is the real source of the= error. > > > > > > Then you can do > > > > > > > > > > DTrace is unavailable on this particular system. > > > > > > > > > > It does indeed fail with ENOTCAPABLE. I have the kern.trap_enotca= p sysctl > > > > > set to 1 so that I can know at exactly what point we're failing, = and > > > > > it's indeed at extattr_get_fd. > > > > > > > > > > Thanks, > > > > > > > > > > -- > > > > > Shawn Webb > > > > > Cofounder / Security Engineer > > > > > HardenedBSD > > > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shaw= n_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > > > Without dtrace, you've got your work cut out for you. I suggest > > > > simply adding all capabilities, verifying that extattr_get_fd works, > > > > and then removing capabilities until it fails. Or, run your program > > > > on vanilla FreeBSD with dtrace. > > > > > > HardenedBSD doesn't have any modifications that would affect Capsicum > > > in this manner. Regardless, I reproduced the problem successfully on > > > FreeBSD 14.0-RELEASE without any code changes. I tried running your > > > DTrace script on FreeBSD 14.0-RELEASE and got this output: > > > > > > =3D=3D=3D=3D BEGIN OUTPUT =3D=3D=3D=3D > > > $ sudo dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $t= arget/ {trace(".");}' -c "obj/hbsdctrl pax list /bin/ls" > > > dtrace: description 'fbt:kernel::return ' matched 31396 probes > > > aslr: sysdef > > > mprotect: sysdef > > > pageexec: sysdef > > > segvguard: sysdef > > > dtrace: pid 29270 has exited > > > CPU ID FUNCTION:NAME > > > 3 47780 foffset_unlock_uio:return . > > > 3 50605 foffset_lock:return . > > > 3 47778 foffset_lock_uio:return . > > > =3D=3D=3D=3D END OUTPUT =3D=3D=3D=3D > > > > > > But I'm still unsure what I'm missing, if anything. > >=20 > > That's red herring. Those functions return void, but dtrace doesn't > > know it. So the "93" is just register garbage. I also notice that > > kern_extattr_get_fd isn't listed. Are you sure that your program is > > really failing with ENOTCAPABLE? You can also try running it with > > ktrace. kdump will show you exactly what capabilities you limited the > > file descriptor to. That can help you verify if you applied the > > limits correctly. >=20 > I'm pretty sure it's failing with ENOTCAPABLE, since the > kern.trap_enotcap sysctl logic is being hit at the point of the > extattr_get_fd syscall. I'll see what I can do > with ktrace. ktrace output captured here: https://hardenedbsd.org/~shawn/2024-03-23_kdump-01.txt The relevant portion is pasted here: =3D=3D=3D=3D BEGIN ktrace OUTPUT =3D=3D=3D=3D 41878 hbsdctrl CALL openat(AT_FDCWD,0x6894a36d4f86,0x500000) 41878 hbsdctrl NAMI "/scratch/tmp/ls" 41878 hbsdctrl RET openat 3 41878 hbsdctrl CALL cap_rights_limit(0x3,0x6894a36d4bc0) 41878 hbsdctrl STRU cap_rights_t CAP_SEEK,CAP_FSTATAT,CAP_EXTATTR_DELETE,= CAP_EXTATTR_GET,CAP_EXTATTR_LIST,CAP_EXTATTR_SET,CAP_ACL_GET 41878 hbsdctrl RET cap_rights_limit 0 41878 hbsdctrl CALL cap_enter 41878 hbsdctrl RET cap_enter 0 41878 hbsdctrl CALL extattr_get_fd(0x3,0x2,0x33ff63afbaf,0,0) 41878 hbsdctrl NAMI "freebsd:system:hbsd.pax.segvguard" 41878 hbsdctrl CAP restricted VFS lookup 41878 hbsdctrl RET extattr_get_fd -1 errno 94 Not permitted in capabilit= y mode 41878 hbsdctrl PSIG SIGTRAP SIG_DFL code=3DTRAP_CAP =3D=3D=3D=3D END ktrace OUTPUT =3D=3D=3D=3D As you can see, I'm adding a bunch more capabilities to the file descriptor. The point of failure is still extattr_get_fd returning ENOTCAPABLE. I'm beginning to suspect that while extattr_get_fd is documented to be allowed with a file descriptor with the CAP_EXTATTR_GET capability, this functionality is broken in FreeBSD. The thing that really confuses me is that the extattr_get_fd syscall entry in syscalls.master has the CAPENABLED flag set: =3D=3D=3D=3D BEGIN syscalls.master =3D=3D=3D=3D 372 AUE_EXTATTR_GET_FD STD|CAPENABLED { ssize_t extattr_get_fd( int fd, int attrnamespace, _In_z_ const char *attrname, _Out_writes_bytes_(nbytes) void *data, size_t nbytes ); } =3D=3D=3D=3D END syscalls.master =3D=3D=3D=3D I think it's now time for me to file a bug report in Bugzilla. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --zogso432rrk4m4bp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmX+7RcACgkQ/y5nonf4 4froBA/9FQFIMjo0iYo8XvF/hWv2iKRoNZo18Sqe84P4h402cW6ornsPwpJ9MI9C 72wYkXPto3WcO4MyFfs9kYoZrzHZqs9EduCmoEgFV10PrXhiAiVMRW98VWay8981 gr9mGNejgbbe5LFWtrV3qIWoxSEhxDGlI55WZhysxcxBrHzmE/WbohPZInN0IaPt SbXYsWeYfriPvMU4A4E6sik7ZhhKG3B7m91z5cKguEwNciTk5LUDQJZiA/oCIALt fHXCeYyNdf7QCLiwq+mYzJ4tLguQX+b02tZDkbGKADD9BofBy1Le1+prnL7TlMOh GWThGhkk2qLYyw3B+++LlpeWB20+Aj2wCO5WK4m78VKh/PRql+Vi4mBu0SV7Gw1C DX/PSMJJeTdDszxP0N9F2i/yymakf0bcXu/yLoOPWPTF46RHEfA18XO4YDRqJ2AC 9qN+F48+FF08YY+l7kXVH3ujheLoVkj6A7jm3wJJMrWapEq5mAc2iR3hnmaSMe2t 6zIc95jNYli1xyRsEczz0OSsLgEz8CiyzIlbhvHARSlgtmXNpjrZai16xMURMtgj LHiadzQ9wP8P4xHAMpxxl9RaTaQBsJLv3H4C9lNxPyFVZDrFOccYniUwRWJHVG9E cjRgI1q8SChIRK9AYaBb/zjyenwdxN7sXphRdO5uuVK1nWaE5SE= =hCeC -----END PGP SIGNATURE----- --zogso432rrk4m4bp-- From nobody Sat Mar 23 16:00:42 2024 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 4V23np4CLKz5FJd2 for ; Sat, 23 Mar 2024 16:00:46 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V23nn1yDCz4jqh for ; Sat, 23 Mar 2024 16:00:45 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=jWDJ+0rp; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d2b as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd2b.google.com with SMTP id ca18e2360f4ac-7c8dd755793so69959339f.0 for ; Sat, 23 Mar 2024 09:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1711209644; x=1711814444; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=U4AOMot1Ahopf4iYS+cqfFU4wm9jwyM6blapkr6zXMw=; b=jWDJ+0rpy0yUnuPj/DMOLnKtao6iqtDPuw2kBxsPOAyWN6IVwUK0gZ12nR2mMUPkyj +sBetBTO6HYI+Em5hIFrnmLOgpgbmYez5WcTMlzCWPoJQR71vzwdQbzpJ6IiORzUcUVY u0UUmky21nxqOgNnPySVP+B3o9Prwwe8DB24EFHY8DnP+sm2imktSuY3mdeI652CPKWT YmIJWzZKGPqN8H/SOv/XOPUyugNYkKjCg7aIP7o0qm2vxpsjso00f9W22r9nkzP3JV+2 zP2JdscWNUbLpPhwehj+uwa8Dw3eu1wEBUtMLNzBig/3pRVMtrpTUB8BWSLXLwX2DjxR cwJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711209644; x=1711814444; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=U4AOMot1Ahopf4iYS+cqfFU4wm9jwyM6blapkr6zXMw=; b=J4uYpGKRbfh9vOAxvkQGWp3k2QvnUETNRHHdDpXNp2sNt0zh4zE6sr1PqjIYeovjT5 aDaJw4b1/B3vjVXZqTqaOC2Na3lQZwaPCn8meElOWCDVe2cHFHntEyzTy0yrB0/s5AXN +E2+vXbUN3qghoUGTp3sX749Tq/F8BS1XAeqjOvlX93P/nBg7HtnnMbbIsNaRFiMSDGL bl9/8a1gn1bTFxpjdkcotdJSQLNSO2DqkGjs1e7W87h/OTTC7Tn1cX54GUd49GyOWBtN GmjediD013OxWfxA9j7y6pQvYCIb++dA5VRqRz/gPa9otaf6/dBxxb2oIAaBV2k91UCk T5dw== X-Forwarded-Encrypted: i=1; AJvYcCV2qrtXnrPGG1N+LP/Kh1KVZAqSXPD0Wt/d5+SOnaSqSFJJE0gnF4R/gV9WZv+gi92kCyMf2+iPCqOBUVoACWgIrKqAw+/3asRIw/o= X-Gm-Message-State: AOJu0Yy0oNHm4hFbGZBynXVJxLG1J/41UhSrC+fBp95JNAiDVhuoAR6y oHv+HmrqXeAQM6kj922Q+xdtRdsd/s+spLTwPKVCbO/tyC6Tv2+FjwhiI/6q73g= X-Google-Smtp-Source: AGHT+IFLEhSS4p+/VxjkQ3kfsGZKOWeyUhOVH+nJuPVDLxyp+AuJabTMcg197uVEcUCGdBH493LgOQ== X-Received: by 2002:a5e:cb0b:0:b0:7cb:dd4a:428d with SMTP id p11-20020a5ecb0b000000b007cbdd4a428dmr2590205iom.10.1711209644091; Sat, 23 Mar 2024 09:00:44 -0700 (PDT) Received: from mutt-hbsd (174-24-72-211.clsp.qwest.net. [174.24.72.211]) by smtp.gmail.com with ESMTPSA id v1-20020a02cba1000000b0047735288d29sm1124581jap.152.2024.03.23.09.00.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Mar 2024 09:00:43 -0700 (PDT) Date: Sat, 23 Mar 2024 16:00:42 +0000 From: Shawn Webb To: alan somers Cc: Alan Somers , freebsd-hackers@freebsd.org Subject: Re: Filesystem extended attributes and Capsicum Message-ID: <56n3xzefvyd3s3b6p3ipggf5hshawrts4nezkw2oud3haihdhj@besj4txt7yar> X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xn2o3mmk6sxwopfh" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2b:from] X-Rspamd-Queue-Id: 4V23nn1yDCz4jqh --xn2o3mmk6sxwopfh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 23, 2024 at 02:54:22PM +0000, Shawn Webb wrote: > On Sat, Mar 23, 2024 at 02:25:26PM +0000, Shawn Webb wrote: > > On Sat, Mar 23, 2024 at 07:58:37AM -0600, alan somers wrote: > > > On Fri, Mar 22, 2024 at 9:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > On Fri, Mar 22, 2024 at 08:07:17PM -0600, Alan Somers wrote: > > > > > On Fri, Mar 22, 2024 at 6:56=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > > > > > > > On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > Hey all, > > > > > > > > > > > > > > > > I'm writing an application in which I hope to enable Capsic= um. I'm > > > > > > > > experiencing an issue whereby extattr_get_fd fails with a f= ile > > > > > > > > descriptor that has all the extended attribute capabilities= enabled > > > > > > > > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > > > > > > > > CAP_EXTATTR_SET). > > > > > > > > > > > > > > > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells= me that > > > > > > > > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > > > > > > > > > > > > > > > So I'm a bit puzzled as to why my call to extattr_get_fd(2)= is > > > > > > > > failing. Am I doing something wrong or are filesystem exten= ded > > > > > > > > attributes not supported in a Capabilities-enabled process? > > > > > > > > > > > > > > > > Here's how I'm creating the file descriptor (before calling > > > > > > > > cap_enter(2)): > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > > > > static int > > > > > > > > open_file(const char *path) > > > > > > > > { > > > > > > > > cap_rights_t rights; > > > > > > > > int fd; > > > > > > > > > > > > > > > > fd =3D open(path, O_PATH | O_CLOEXEC); > > > > > > > > if (fd =3D=3D -1) { > > > > > > > > return (-1); > > > > > > > > } > > > > > > > > > > > > > > > > memset(&rights, 0, sizeof(rights)); > > > > > > > > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EX= TATTR_GET, > > > > > > > > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > > > > > > > > cap_rights_limit(fd, &rights); > > > > > > > > > > > > > > > > return (fd); > > > > > > > > } > > > > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > > > > > > > Eventually, after calling cap_enter(2), the following code = is called: > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > > > > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > > > > > > > > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNA= ME_ENABLED, NULL, 0); > > > > > > > > if (sz <=3D 0) { > > > > > > > > if (errno =3D=3D ENOATTR) { > > > > > > > > /* > > > > > > > > * This is okay, it just means that = nothing has been set. > > > > > > > > * No error condition here. > > > > > > > > */ > > > > > > > > return (RES_SUCCESS); > > > > > > > > } > > > > > > > > return (RES_FAIL); > > > > > > > > } > > > > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > > > > > > > For reference, the program's code is here: > > > > > > > > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main= ?ref_type=3Dheads > > > > > > > > > > > > > > > > The library code, which is what's responsible for calling t= he > > > > > > > > filesystem extended attribute related syscalls is here: > > > > > > > > > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/= hardened/current/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > > > > > > > > > > > > > > > From the rights(4) manual page, I'm instructed all I need a= re to apply > > > > > > > > those capabilities to that file descriptor: > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > > > > > > > > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > > > > > > > > > > > > > > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > > > > > > > > > > > > > > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > > > > > > > > > > > > > > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > > > > > > > > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > > > > > > > > > > > > > > > So I'm a bit unsure if I'm doing something wrong. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > -- > > > > > > > > Shawn Webb > > > > > > > > Cofounder / Security Engineer > > > > > > > > HardenedBSD > > > > > > > > > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/maste= r/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > > > > > > > > > What error code does it fail with? If it's ENOTCAPABLE, then= I > > > > > > > suggest using dtrace to find the reason why it fails. Do som= ething > > > > > > > like this: > > > > > > > > > > > > > > dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $= target/ > > > > > > > {trace(".");}' -c ./my_application > > > > > > > > > > > > > > That will print the name of every non-inlined kernel function= that > > > > > > > returns ENOTCAPABLE during your process. But it will also pr= int the > > > > > > > names of any other kernel functions that return an integer va= lue of > > > > > > > 93. From there, guess which function is the real source of t= he error. > > > > > > > Then you can do > > > > > > > > > > > > DTrace is unavailable on this particular system. > > > > > > > > > > > > It does indeed fail with ENOTCAPABLE. I have the kern.trap_enot= cap sysctl > > > > > > set to 1 so that I can know at exactly what point we're failing= , and > > > > > > it's indeed at extattr_get_fd. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -- > > > > > > Shawn Webb > > > > > > Cofounder / Security Engineer > > > > > > HardenedBSD > > > > > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Sh= awn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > > > > > Without dtrace, you've got your work cut out for you. I suggest > > > > > simply adding all capabilities, verifying that extattr_get_fd wor= ks, > > > > > and then removing capabilities until it fails. Or, run your prog= ram > > > > > on vanilla FreeBSD with dtrace. > > > > > > > > HardenedBSD doesn't have any modifications that would affect Capsic= um > > > > in this manner. Regardless, I reproduced the problem successfully on > > > > FreeBSD 14.0-RELEASE without any code changes. I tried running your > > > > DTrace script on FreeBSD 14.0-RELEASE and got this output: > > > > > > > > =3D=3D=3D=3D BEGIN OUTPUT =3D=3D=3D=3D > > > > $ sudo dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D = $target/ {trace(".");}' -c "obj/hbsdctrl pax list /bin/ls" > > > > dtrace: description 'fbt:kernel::return ' matched 31396 probes > > > > aslr: sysdef > > > > mprotect: sysdef > > > > pageexec: sysdef > > > > segvguard: sysdef > > > > dtrace: pid 29270 has exited > > > > CPU ID FUNCTION:NAME > > > > 3 47780 foffset_unlock_uio:return . > > > > 3 50605 foffset_lock:return . > > > > 3 47778 foffset_lock_uio:return . > > > > =3D=3D=3D=3D END OUTPUT =3D=3D=3D=3D > > > > > > > > But I'm still unsure what I'm missing, if anything. > > >=20 > > > That's red herring. Those functions return void, but dtrace doesn't > > > know it. So the "93" is just register garbage. I also notice that > > > kern_extattr_get_fd isn't listed. Are you sure that your program is > > > really failing with ENOTCAPABLE? You can also try running it with > > > ktrace. kdump will show you exactly what capabilities you limited the > > > file descriptor to. That can help you verify if you applied the > > > limits correctly. > >=20 > > I'm pretty sure it's failing with ENOTCAPABLE, since the > > kern.trap_enotcap sysctl logic is being hit at the point of the > > extattr_get_fd syscall. I'll see what I can do > > with ktrace. >=20 > ktrace output captured here: > https://hardenedbsd.org/~shawn/2024-03-23_kdump-01.txt >=20 > The relevant portion is pasted here: >=20 > =3D=3D=3D=3D BEGIN ktrace OUTPUT =3D=3D=3D=3D > 41878 hbsdctrl CALL openat(AT_FDCWD,0x6894a36d4f86,0x500000) > 41878 hbsdctrl NAMI "/scratch/tmp/ls" > 41878 hbsdctrl RET openat 3 > 41878 hbsdctrl CALL cap_rights_limit(0x3,0x6894a36d4bc0) > 41878 hbsdctrl STRU cap_rights_t CAP_SEEK,CAP_FSTATAT,CAP_EXTATTR_DELET= E,CAP_EXTATTR_GET,CAP_EXTATTR_LIST,CAP_EXTATTR_SET,CAP_ACL_GET > 41878 hbsdctrl RET cap_rights_limit 0 > 41878 hbsdctrl CALL cap_enter > 41878 hbsdctrl RET cap_enter 0 > 41878 hbsdctrl CALL extattr_get_fd(0x3,0x2,0x33ff63afbaf,0,0) > 41878 hbsdctrl NAMI "freebsd:system:hbsd.pax.segvguard" > 41878 hbsdctrl CAP restricted VFS lookup > 41878 hbsdctrl RET extattr_get_fd -1 errno 94 Not permitted in capabil= ity mode > 41878 hbsdctrl PSIG SIGTRAP SIG_DFL code=3DTRAP_CAP > =3D=3D=3D=3D END ktrace OUTPUT =3D=3D=3D=3D >=20 > As you can see, I'm adding a bunch more capabilities to the file > descriptor. The point of failure is still extattr_get_fd returning > ENOTCAPABLE. >=20 > I'm beginning to suspect that while extattr_get_fd is documented to be > allowed with a file descriptor with the CAP_EXTATTR_GET capability, > this functionality is broken in FreeBSD. >=20 > The thing that really confuses me is that the extattr_get_fd syscall > entry in syscalls.master has the CAPENABLED flag set: >=20 > =3D=3D=3D=3D BEGIN syscalls.master =3D=3D=3D=3D > 372 AUE_EXTATTR_GET_FD STD|CAPENABLED { > ssize_t extattr_get_fd( > int fd, > int attrnamespace, > _In_z_ const char *attrname, > _Out_writes_bytes_(nbytes) void *data, > size_t nbytes > ); > } > =3D=3D=3D=3D END syscalls.master =3D=3D=3D=3D >=20 > I think it's now time for me to file a bug report in Bugzilla. Bug report submitted: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277908 Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --xn2o3mmk6sxwopfh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmX+/KMACgkQ/y5nonf4 4foFgA//RTaCHil4pBIVeatq8TpQJd3CCRUs3tdoMjpsvblOKWNEyHtwgzXUWMzY DOd7IJKV17LG0xOW00Tm0nFA0NTAgq6VULLP49G3OjMnSTsQfPd2MYEpPGYmyHVX 89rYlk96f2JCVnu4wJ97spUnSi91uQoFVLQyTgBQ5QXu5jes+Qi43QDU5mxhtxGY FrtifdkDPsFWsPXoX3cphGbzSEYLMqKqfblmBRQIhaPzzWB3IAbZ+gB2ozCt307I 1iIWUd9wEbvvMzYKOm8VMedzxiS2ro0Q52zTIklZSJzZuy9sKa1e+BzJtQA4YLRO 2w3orpCu6WLqfsaq109Ijjz7mtP3Wfo+6rBEcNRdNfXLtlL14VxnZ3BayJj3gGeN vg5LV8Wl6CQjvCC/iKc+wWwX2FQFUD19+Z5KfzID22t1+ZnASVGzNiH8AJjglj2h cKKEoBuV9cqGpDTIdYUUarf9ufesgNDXPVw3hofLd//hHVqvERtZrGt/KWZBmX6l rgdQYJSXA5QWV8JuNkV/gH++nQo/iounoYZandr/9DU2hnoFwOSAuLemo2oaG6Ll ZBukjz1KWq8FuwYzRPU52rsVbZ6kXLd7awOHNtz1/1vEraXZv0DODiO05geLp9v9 NiLnjLUD5m9bO9S9ruREE5LEmencvxqUOcY287Ia0wiTsffJPE0= =d1j/ -----END PGP SIGNATURE----- --xn2o3mmk6sxwopfh-- From nobody Sat Mar 23 16:06:35 2024 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 4V23wZ6VyCz5FKKD for ; Sat, 23 Mar 2024 16:06:38 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V23wZ3Xk0z4lQN for ; Sat, 23 Mar 2024 16:06:38 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=FwQd0Lmm; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::d31 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-io1-xd31.google.com with SMTP id ca18e2360f4ac-7cf092f6bb7so126951739f.3 for ; Sat, 23 Mar 2024 09:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1711209997; x=1711814797; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=m2Z6Mi5nVDIOLpL6RGxY1mU6rn5mGvTWpdUgWIT5E+U=; b=FwQd0Lmm6N0OnbSWDIPPDkQ/V8vXCivNvkE8WMIKhvfSVRGzS6M4FJJpG7z0KoDD7u 1HvUmMTRUTFK3mxiwzXWJ7DE1ArE57tyM+NkGH1kvK9eOt3fPZUq7Z7ida75uUn/E0QZ iMo9WtN8SxohWGV5mseNPjmdxia2xsrbgMRmydQCvk1sekqfPx9DeJjo1Dkx4fhE+Wqb i4C0bZJ+r+glFoIRO2gVsHGN94Yf73kamTVS13/UHGsXFzQ3w1M+QItMG0oUcceGke9f uuH27JtaVgm27TQh3Pnym0Jw/4GZN93G801tXm+Q8/LHvdZ8LdrCRd6SqJIzuuqspmyo Yrvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711209997; x=1711814797; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=m2Z6Mi5nVDIOLpL6RGxY1mU6rn5mGvTWpdUgWIT5E+U=; b=lPv4fLazD9ax2/xok+//jOxC/rJ627BDKLxiIiKGzjbSjiXAbxDCdo/2BkHUUXRyM9 dYDHCUbYlhJiHDtXOYxOxlKiJEHs8G5C8ihDh/kV9gBYPeu6l7os4KZd/6HoZGXcziJ/ PxjUZxokM5gtSQ8EyeCCSSChBogG9NoSGqezqqEBl8Ki+z/mOhlZnDl/F2+a4JRKt1dc DM6/N6Nv5olCSMEkNrYOA/sRBHpo8L978X6j/PbSiiZhXa2MNf1dTPOHWAIFYFuBEXBy 1oepVcZfZMHd4y3PHF6wnbCPVxch4GQMeVMkCzPEA2LtbsD1P6Sd6Pu7qk6ng3qTxDJI dZ1w== X-Forwarded-Encrypted: i=1; AJvYcCW7mAEQbzJEeKp4Iv525hBNwCTqE02kEV12oCWaQhOxiy1ICLw2tCxepDPWVLmpcVSQZEcdoDjOKowF20G/8jOBbCYDiBfg0bNKYxU= X-Gm-Message-State: AOJu0Yw3QmHYci4bh8yQ7MqbxYdk8BTgXlGMLrULxtjDeIrMeYs9Dwzb Soi1cigHdF60LUED3bPsElsyugEu5fidZszWlYCRqjJW1cAmDkA9DOkpDgfMiwvOUITu4cqZnNb 0 X-Google-Smtp-Source: AGHT+IEj2byfFQf4iKeM7F8LyrIp2NghrpGbTe4CmcjZIDxaZNYsSt8y6twmvwfND406IVTGf59gzA== X-Received: by 2002:a5e:de49:0:b0:7d0:2d83:1519 with SMTP id e9-20020a5ede49000000b007d02d831519mr2967845ioq.4.1711209997142; Sat, 23 Mar 2024 09:06:37 -0700 (PDT) Received: from mutt-hbsd (174-24-72-211.clsp.qwest.net. [174.24.72.211]) by smtp.gmail.com with ESMTPSA id g8-20020a02b708000000b0047469b04c35sm1142741jam.65.2024.03.23.09.06.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Mar 2024 09:06:36 -0700 (PDT) Date: Sat, 23 Mar 2024 16:06:35 +0000 From: Shawn Webb To: alan somers Cc: Alan Somers , freebsd-hackers@freebsd.org Subject: Re: Filesystem extended attributes and Capsicum Message-ID: X-Operating-System: FreeBSD mutt-hbsd 15.0-CURRENT-HBSD FreeBSD 15.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <56n3xzefvyd3s3b6p3ipggf5hshawrts4nezkw2oud3haihdhj@besj4txt7yar> 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qpnblpzeya3764pj" Content-Disposition: inline In-Reply-To: <56n3xzefvyd3s3b6p3ipggf5hshawrts4nezkw2oud3haihdhj@besj4txt7yar> X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DMARC_NA(0.00)[hardenedbsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d31:from] X-Rspamd-Queue-Id: 4V23wZ3Xk0z4lQN --qpnblpzeya3764pj Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 23, 2024 at 04:00:42PM +0000, Shawn Webb wrote: > On Sat, Mar 23, 2024 at 02:54:22PM +0000, Shawn Webb wrote: > > On Sat, Mar 23, 2024 at 02:25:26PM +0000, Shawn Webb wrote: > > > On Sat, Mar 23, 2024 at 07:58:37AM -0600, alan somers wrote: > > > > On Fri, Mar 22, 2024 at 9:52=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > On Fri, Mar 22, 2024 at 08:07:17PM -0600, Alan Somers wrote: > > > > > > On Fri, Mar 22, 2024 at 6:56=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > > > > > > > > On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > > > > > > > > > > > > > > > > > Hey all, > > > > > > > > > > > > > > > > > > I'm writing an application in which I hope to enable Caps= icum. I'm > > > > > > > > > experiencing an issue whereby extattr_get_fd fails with a= file > > > > > > > > > descriptor that has all the extended attribute capabiliti= es enabled > > > > > > > > > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, a= nd > > > > > > > > > CAP_EXTATTR_SET). > > > > > > > > > > > > > > > > > > Looking at the kernel source (sys/kern/vfs_extattr.c) tel= ls me that > > > > > > > > > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > > > > > > > > > > > > > > > > > So I'm a bit puzzled as to why my call to extattr_get_fd(= 2) is > > > > > > > > > failing. Am I doing something wrong or are filesystem ext= ended > > > > > > > > > attributes not supported in a Capabilities-enabled proces= s? > > > > > > > > > > > > > > > > > > Here's how I'm creating the file descriptor (before calli= ng > > > > > > > > > cap_enter(2)): > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > > > > > static int > > > > > > > > > open_file(const char *path) > > > > > > > > > { > > > > > > > > > cap_rights_t rights; > > > > > > > > > int fd; > > > > > > > > > > > > > > > > > > fd =3D open(path, O_PATH | O_CLOEXEC); > > > > > > > > > if (fd =3D=3D -1) { > > > > > > > > > return (-1); > > > > > > > > > } > > > > > > > > > > > > > > > > > > memset(&rights, 0, sizeof(rights)); > > > > > > > > > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_= EXTATTR_GET, > > > > > > > > > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > > > > > > > > > cap_rights_limit(fd, &rights); > > > > > > > > > > > > > > > > > > return (fd); > > > > > > > > > } > > > > > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > Eventually, after calling cap_enter(2), the following cod= e is called: > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > > > > > > > > > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > > > > > > > > > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTR= NAME_ENABLED, NULL, 0); > > > > > > > > > if (sz <=3D 0) { > > > > > > > > > if (errno =3D=3D ENOATTR) { > > > > > > > > > /* > > > > > > > > > * This is okay, it just means tha= t nothing has been set. > > > > > > > > > * No error condition here. > > > > > > > > > */ > > > > > > > > > return (RES_SUCCESS); > > > > > > > > > } > > > > > > > > > return (RES_FAIL); > > > > > > > > > } > > > > > > > > > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > For reference, the program's code is here: > > > > > > > > > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/ma= in?ref_type=3Dheads > > > > > > > > > > > > > > > > > > The library code, which is what's responsible for calling= the > > > > > > > > > filesystem extended attribute related syscalls is here: > > > > > > > > > > > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tre= e/hardened/current/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > > > > > > > > > > > > > > > > > From the rights(4) manual page, I'm instructed all I need= are to apply > > > > > > > > > those capabilities to that file descriptor: > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > > > > > > > > > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > > > > > > > > > > > > > > > > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > > > > > > > > > > > > > > > > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > > > > > > > > > > > > > > > > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > > > > > > > > > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > > > > > > > > > > > > > > > > > So I'm a bit unsure if I'm doing something wrong. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Shawn Webb > > > > > > > > > Cofounder / Security Engineer > > > > > > > > > HardenedBSD > > > > > > > > > > > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/mas= ter/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > > > > > > > > > > > What error code does it fail with? If it's ENOTCAPABLE, th= en I > > > > > > > > suggest using dtrace to find the reason why it fails. Do s= omething > > > > > > > > like this: > > > > > > > > > > > > > > > > dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D= $target/ > > > > > > > > {trace(".");}' -c ./my_application > > > > > > > > > > > > > > > > That will print the name of every non-inlined kernel functi= on that > > > > > > > > returns ENOTCAPABLE during your process. But it will also = print the > > > > > > > > names of any other kernel functions that return an integer = value of > > > > > > > > 93. From there, guess which function is the real source of= the error. > > > > > > > > Then you can do > > > > > > > > > > > > > > DTrace is unavailable on this particular system. > > > > > > > > > > > > > > It does indeed fail with ENOTCAPABLE. I have the kern.trap_en= otcap sysctl > > > > > > > set to 1 so that I can know at exactly what point we're faili= ng, and > > > > > > > it's indeed at extattr_get_fd. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > -- > > > > > > > Shawn Webb > > > > > > > Cofounder / Security Engineer > > > > > > > HardenedBSD > > > > > > > > > > > > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/= Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > > > > > > > > > Without dtrace, you've got your work cut out for you. I suggest > > > > > > simply adding all capabilities, verifying that extattr_get_fd w= orks, > > > > > > and then removing capabilities until it fails. Or, run your pr= ogram > > > > > > on vanilla FreeBSD with dtrace. > > > > > > > > > > HardenedBSD doesn't have any modifications that would affect Caps= icum > > > > > in this manner. Regardless, I reproduced the problem successfully= on > > > > > FreeBSD 14.0-RELEASE without any code changes. I tried running yo= ur > > > > > DTrace script on FreeBSD 14.0-RELEASE and got this output: > > > > > > > > > > =3D=3D=3D=3D BEGIN OUTPUT =3D=3D=3D=3D > > > > > $ sudo dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D= =3D $target/ {trace(".");}' -c "obj/hbsdctrl pax list /bin/ls" > > > > > dtrace: description 'fbt:kernel::return ' matched 31396 probes > > > > > aslr: sysdef > > > > > mprotect: sysdef > > > > > pageexec: sysdef > > > > > segvguard: sysdef > > > > > dtrace: pid 29270 has exited > > > > > CPU ID FUNCTION:NAME > > > > > 3 47780 foffset_unlock_uio:return . > > > > > 3 50605 foffset_lock:return . > > > > > 3 47778 foffset_lock_uio:return . > > > > > =3D=3D=3D=3D END OUTPUT =3D=3D=3D=3D > > > > > > > > > > But I'm still unsure what I'm missing, if anything. > > > >=20 > > > > That's red herring. Those functions return void, but dtrace doesn't > > > > know it. So the "93" is just register garbage. I also notice that > > > > kern_extattr_get_fd isn't listed. Are you sure that your program is > > > > really failing with ENOTCAPABLE? You can also try running it with > > > > ktrace. kdump will show you exactly what capabilities you limited = the > > > > file descriptor to. That can help you verify if you applied the > > > > limits correctly. > > >=20 > > > I'm pretty sure it's failing with ENOTCAPABLE, since the > > > kern.trap_enotcap sysctl logic is being hit at the point of the > > > extattr_get_fd syscall. I'll see what I can do > > > with ktrace. > >=20 > > ktrace output captured here: > > https://hardenedbsd.org/~shawn/2024-03-23_kdump-01.txt > >=20 > > The relevant portion is pasted here: > >=20 > > =3D=3D=3D=3D BEGIN ktrace OUTPUT =3D=3D=3D=3D > > 41878 hbsdctrl CALL openat(AT_FDCWD,0x6894a36d4f86,0x500000) > > 41878 hbsdctrl NAMI "/scratch/tmp/ls" > > 41878 hbsdctrl RET openat 3 > > 41878 hbsdctrl CALL cap_rights_limit(0x3,0x6894a36d4bc0) > > 41878 hbsdctrl STRU cap_rights_t CAP_SEEK,CAP_FSTATAT,CAP_EXTATTR_DEL= ETE,CAP_EXTATTR_GET,CAP_EXTATTR_LIST,CAP_EXTATTR_SET,CAP_ACL_GET > > 41878 hbsdctrl RET cap_rights_limit 0 > > 41878 hbsdctrl CALL cap_enter > > 41878 hbsdctrl RET cap_enter 0 > > 41878 hbsdctrl CALL extattr_get_fd(0x3,0x2,0x33ff63afbaf,0,0) > > 41878 hbsdctrl NAMI "freebsd:system:hbsd.pax.segvguard" > > 41878 hbsdctrl CAP restricted VFS lookup > > 41878 hbsdctrl RET extattr_get_fd -1 errno 94 Not permitted in capab= ility mode > > 41878 hbsdctrl PSIG SIGTRAP SIG_DFL code=3DTRAP_CAP > > =3D=3D=3D=3D END ktrace OUTPUT =3D=3D=3D=3D > >=20 > > As you can see, I'm adding a bunch more capabilities to the file > > descriptor. The point of failure is still extattr_get_fd returning > > ENOTCAPABLE. > >=20 > > I'm beginning to suspect that while extattr_get_fd is documented to be > > allowed with a file descriptor with the CAP_EXTATTR_GET capability, > > this functionality is broken in FreeBSD. > >=20 > > The thing that really confuses me is that the extattr_get_fd syscall > > entry in syscalls.master has the CAPENABLED flag set: > >=20 > > =3D=3D=3D=3D BEGIN syscalls.master =3D=3D=3D=3D > > 372 AUE_EXTATTR_GET_FD STD|CAPENABLED { > > ssize_t extattr_get_fd( > > int fd, > > int attrnamespace, > > _In_z_ const char *attrname, > > _Out_writes_bytes_(nbytes) void *data, > > size_t nbytes > > ); > > } > > =3D=3D=3D=3D END syscalls.master =3D=3D=3D=3D > >=20 > > I think it's now time for me to file a bug report in Bugzilla. >=20 > Bug report submitted: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277908 Last message, sorry to bother. ZFS is indeed the culprit here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277908#c1 Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --qpnblpzeya3764pj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmX+/gsACgkQ/y5nonf4 4folIw//W8aSWovfB3l7W3jW93QXFinDE9qmXzMbxMzs2cTVoi8l7GwENxaJIuNb jDC74U4UeH/XBg6Ws+qVjpgj9ncqguS/dcRl/vdmBTAUegkb3gJzjsQO14MnwlnJ 8PCuGVRXrogSZRsQGhuyKbh7SXiCct/077uxO+iggD9r0GPyETWa8wHHZKtgOUNL esy4cIJD77C2wYQEm7dRpPhWuS5Do6bvpApNthZ9XtDFoiKlbmvLLfVft+5NDMXL XpLGSoz0h+9O1xNi72OfMwST0P3cpmEsz1x7NrHqHwde2JOk1g5g/wqSEexTi5Mb U5Bh6BNSnItroF6YDbXMrr0JrSkI/0XlRHwJuFgC/4i4nMVpjsXKPRdv8xgH7mle /ZCyDdwiaNgmU0+hFi/z8Uqqom161p4w/2WWOtp6AeMwVD7yYkL7D7w1TjoSt7iy WKBFy5kkH2HFPm6QSFN/K68zBaZ+cnl2FQBg70F6exN6/blkByo6E3y3uEGatksJ J8E5u/bzEBDA/9s+rYiW1wJQpBQ7RVDE94yFms5fbWeW1Ze3g4cx/McRv1aLAunR tFxnXWpAb5/45DY+RW0S0OEM9GxoPZgPqG/AuGAWfOeRE+TlxVQpdoZnDb6mT5uS 51Gr8zgw/WWF/VYEHPE/VPZqV86HzTodfg0qYUDSMGJ9ih4wNkw= =sJBp -----END PGP SIGNATURE----- --qpnblpzeya3764pj-- From nobody Sun Mar 24 00:01:07 2024 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 4V2GS35bfHz5G9GW; Sun, 24 Mar 2024 00:01:07 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V2GS349KJz4ZkB; Sun, 24 Mar 2024 00:01:07 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711238467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=wQRuhnGxjGDxWCKVSidOba/8XIYV/+IJAobT8GnlIo8=; b=l705n5EqX81nOBVKZL4NfF8L7RCuZ9TMlkrIjxfDMjaQ3HVfGUw2UCZJVlZlTMjzsxP3rV jiCqHOuDdF++RjZeIsg0f9um7P+dok0ovw+C4uvxwnrOWZ6Ra7ARrYwqyupe5vhLtnFoaT kNMYaSgQfYu6X8WZ/JWD3TUifO70pyBpBI+Vg9fE9m6TPAnr2EShzJomJCad9YyP+QtpQ5 U2PFLvD7pkGhAi74i+z4ARp1Igaygd424/1jgwqU5SIdt/AU7JoKJd6L6v2IWd3dknxC8d rf29nBZUk6l/1wEpq2YHCgMkGbMJrkotajHtJRBfmxxIV/gmvh9fcJlgu0sKZw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711238467; a=rsa-sha256; cv=none; b=ORVlEG7lh+aI4jsbmx9ZB1PhQYV9pOEARSYg7p3NEbpMsQpR+m3rd9qwACjyHGqZWbr3Qe 1CmIRHXNQNpbV1hkeDVDHYjZhCLM3I5M0ZNFsjU19OdV6L74yorgg+spbuOJA4UOS4mcfy kWgFusm/qNY/sFWsyFwLpG+3iuyLCy5QBvSPJhKOTKextfH0DitmkShhERprD8NfbKimRA P1Ebj994fN6IdEKF46fVJPEwN4K1Re3624BZHbsCeWW1Yi/i+MtfMGqPx2ywi248eBoWUz a9QaH6jPk+GNqdaekB+VCOrVrOVjApPmuTLKeel/a/pPlfev9aogxnYiby9R4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711238467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=wQRuhnGxjGDxWCKVSidOba/8XIYV/+IJAobT8GnlIo8=; b=hCSd4T0MKI8RXoBfdSBHQpYQ3/yUMYpQazByHi/pae144UBatGN8DmTDCXEIWFHMueie4A 6NFRwk5vvKZqbv5JbHZb24mKar9rjcz43HsiMJuJou8ZtvitlXPe1f7aZFtGRVaPVl3Xcm qVySzFNBB1IvP6HXvygohYWE2tT4z7IV36xGdZl54JcIcan2Rt3jS3IlljJXRPyNveXJa7 7iLSHfiwJL+DI46hGCSN7gEbxPpxvEpbijIPHoUudvWBawxnASNmAalozLk4ySxG3uKzfX Fdm9Zv/xwzjHYBQQNCVFSUtAAYSGCjuipd1JeYGUFSJrXM8ZFF+bofhQI2AOLA== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 6BADF172E9; Sun, 24 Mar 2024 00:01:07 +0000 (UTC) To: freebsd-status-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2024Q1 status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,secretary@asiabsdcon.org Message-Id: <20240324000107.6BADF172E9@freefall.freebsd.org> Date: Sun, 24 Mar 2024 00:01:07 +0000 (UTC) From: Lorenzo Salvadore 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 Dear FreeBSD Community, The deadline for the next FreeBSD Status Report update is March, 31st 2024 for work done since the last round of quarterly reports: January 2024 - March 2024. I would like to remind you that reports are published on a quarterly basis and are usually collected during the last month of each quarter, You are also welcome to submit them even earlier if you want, and the earlier you submit them, the more time we have for reviewing. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The following methods are available to submit your reports: * submit a review on Phabricator and add the group "status" to the reviewers list. You should put your reports in the directory doc/website/content/en/status/report-2024-01-2024-03/ (create it if it is missing); * submit a pull request at . You should put your reports in the directory doc/website/content/en/status/report-2024-01-2024-03/ (create it if it is missing); * send an email to status-submissions@FreeBSD.org including your report. An AsciiDoc template is available at . We look forward to seeing your 2024Q1 reports! Thanks, Lorenzo Salvadore (on behalf of status@) From nobody Sun Mar 24 12:57:01 2024 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 4V2bgk5TXYz5FcfM for ; Sun, 24 Mar 2024 12:57:22 +0000 (UTC) (envelope-from tom@tomforb.es) Received: from fhigh8-smtp.messagingengine.com (fhigh8-smtp.messagingengine.com [103.168.172.159]) (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 4V2bgk0Sklz4mpr for ; Sun, 24 Mar 2024 12:57:22 +0000 (UTC) (envelope-from tom@tomforb.es) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tomforb.es header.s=fm3 header.b=kOwageDy; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=mZXN18x+; dmarc=none; spf=pass (mx1.freebsd.org: domain of tom@tomforb.es designates 103.168.172.159 as permitted sender) smtp.mailfrom=tom@tomforb.es Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id CE0E211400BD for ; Sun, 24 Mar 2024 08:57:21 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute2.internal (MEProxy); Sun, 24 Mar 2024 08:57:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomforb.es; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1711285041; x=1711371441; bh=7WZkz6ZxwARAmcxIV9k2E5aLOwK1CRYR e16gw7/SfhQ=; b=kOwageDyd5iN6/w92IuP+ed9uLPWFjc4ZVso5rdPQv7IgarE 8kO2WT9NVRoG9DyJ4lNUvTbtp0wckBIfIzROz3lHQSTViA3vYyUFBlexlBiUrdGJ EiEd+xQwIamO8NpbrikMs3gdARL5leRkmGqaQellE12OJHT0boswtejd9aIQskOE qZgGhbng03QeSvm87MCa5/p81nu6m0wYFNLmQygrBy+mHOurvoRkj+3K3Or4YpUE v6ZaWvhlIBeYN8U4fVMp1KqmPctkgg2cXCljgAFvRR4P/bXM1koHOrPhg65nBiDu UA6rd9NHM8P2jHdyQmQFs2aeEVUZsXuzP+Xw5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1711285041; x=1711371441; bh=7WZkz6ZxwARAmcxIV9k2E5aLOwK1CRYRe16 gw7/SfhQ=; b=mZXN18x+sXQCh2QYGVjJbhCS5WpfWQHhZfQh2saGoG6I/npetfn oDOfyhLZi3Luh/Dv8XUYn1zPeWiFxIPJKzCC3DWkex/Z6DJ/wK82htc+hnN6VBm4 o9qd9vCdu0/8eO14AfV03LuaJZ3JZe2Gt56UCKFctm3VLUxA3YxmEzjMSwkcxQHh qQHXx1Se4FbnmcuKhgOnCmgAMtvOd7GmrWG5IauBM1YKFpMXSc3lIyayFkjRSXjY FFb8GhDouscDeJmQ1ESFc2DEyT3aenNN2EiKzDmL0jQynjQufzPN38NCFLT7F5ly k4q7Wrlnfydkhakvmza42YaWwUDEz44R92Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtjedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfvfhomhcuhfhorhgsvghsfdcuoehtohhmsehtohhmfhhorhgs rdgvsheqnecuggftrfgrthhtvghrnhepgfeggfefkeeftedvteduleduvdehieeljeetke ektdfgjefhheeltddvleeuuefgnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtohhmsehtoh hmfhhorhgsrdgvsh X-ME-Proxy: Feedback-ID: i915146fc:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 94F432D4007D; Sun, 24 Mar 2024 08:57:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-332-gdeb4194079-fm-20240319.002-gdeb41940 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 Message-Id: <954e1d80-d44f-4c3d-88a7-122dc0f25de4@app.fastmail.com> Date: Sun, 24 Mar 2024 12:57:01 +0000 From: "Tom Forbes" To: freebsd-hackers@freebsd.org Subject: Removing or changing the ping interval restriction for non-root users Content-Type: multipart/alternative; boundary=fc4cbc23ee3b47c2993003d0279288d0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.58 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27:c]; R_DKIM_ALLOW(-0.20)[tomforb.es:s=fm3,messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.159:from]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[tom]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[tomforb.es]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[tomforb.es:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4V2bgk0Sklz4mpr --fc4cbc23ee3b47c2993003d0279288d0 Content-Type: text/plain Hello, I maintain a small project called gping[1] that recently added support for FreeBSD. One of the issues I ran into with running this on FreeBSD was that the `ping` command seems to disallow intervals of less than 1 second if you are not running as root[2]. This check was last touched 23 years ago and I'm curious as to why this restriction exists? I assume it's from an earlier time in the internets history, and perhaps is related to potential misuse of the command to flood targets with packets via ping? If it is then I'd like to suggest that this limitation be removed or is reduced to `0.1` seconds instead? Using `ping` for this kind of thing isn't a viable attack today, and the 1 second limitation seems like it would get in the way of useful uses of the ping command. Also this is my first post to any *BSD mailing list, so please let me know if this is not the right place to ask this question or propose this! Thanks, Tom 1. https://github.com/orf/gping 2. https://github.com/freebsd/freebsd-src/blame/8a56ef8d75b42ee7228247466c8c1712de6e3b6f/sbin/ping/ping6.c#L441 --fc4cbc23ee3b47c2993003d0279288d0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hello,
I maintain a small project called gping[1] that recently added = support for FreeBSD. One of the issues I ran into with running this on F= reeBSD was that the `ping` command seems to disallow intervals of less t= han 1 second if you are not running as root[2]. This check was last touc= hed 23 years ago and I'm curious as to why this restriction exists? I as= sume it's from an earlier time in the internets history, and perhaps is = related to potential misuse of the command to flood targets with packets= via ping?

If it is then I'd li= ke to suggest that this limitation be removed or is reduced to `0.1` sec= onds instead? Using `ping` for this kind of thing isn't a viable attack = today, and the 1 second limitation seems like it would get in the way of= useful uses of the ping command.
Also this is my first post to any *BSD mailing list, so please let me= know if this is not the right place to ask this question or propose thi= s!

Thanks,=
Tom

2. https://github.com/freebsd/freebsd-src/blame/8a= 56ef8d75b42ee7228247466c8c1712de6e3b6f/sbin/ping/ping6.c#L441
--fc4cbc23ee3b47c2993003d0279288d0-- From nobody Sun Mar 24 14:48:35 2024 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 4V2f870VpDz5Fr01 for ; Sun, 24 Mar 2024 14:48:39 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V2f865lYfz44YT for ; Sun, 24 Mar 2024 14:48:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id oLdcrTX6QdrxEoP9KrOM69; Sun, 24 Mar 2024 14:48:38 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPSA id oP9IrpzLEByQroP9JrzSzX; Sun, 24 Mar 2024 14:48:37 +0000 X-Authority-Analysis: v=2.4 cv=UOF+Hzfy c=1 sm=1 tr=0 ts=66003d45 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=IkcTkHD0fZMA:10 a=K6JAEmCyrfEA:10 a=puQWGBksFvoA:10 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=m_3L-afJOhMsJdpAJRIA:9 a=QEXdDO2ut3YA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from [127.0.0.1] (walden [192.168.0.252]) by spqr.komquats.com (Postfix) with ESMTPSA id 30CA65D8; Sun, 24 Mar 2024 07:48:36 -0700 (PDT) Date: Sun, 24 Mar 2024 07:48:35 -0700 From: Cy Schubert To: freebsd-hackers@freebsd.org, Tom Forbes Subject: =?US-ASCII?Q?Re=3A_Removing_or_changing_the_ping_in?= =?US-ASCII?Q?terval_restriction_for_non-root_users?= In-Reply-To: <954e1d80-d44f-4c3d-88a7-122dc0f25de4@app.fastmail.com> References: <954e1d80-d44f-4c3d-88a7-122dc0f25de4@app.fastmail.com> Message-ID: <2D5DD001-DD98-4A8E-9458-6754E6D977EE@cschubert.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=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfCHyZbXTJKA46/DLka7eGnuOYugzTqQi9F+ONPENBpzrZ1/18IUCZmOA+Dbo7lVboMZWWvPvZcX0lCUqtTUsOWto8yyV4s4ycRgfKvkZQaiI3nIPt2K8 mNfUU+RyFt2Nlo0zAaH36Kq7hrVhYS5XQ+nFZcaA/1R0fZoUt9e4HSy66cgbVyq+K1hkELitv4oS6NcGjGOpGJNELIxiGvUWHYO54UgQZgUTpUDLBDxdBJ+/ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4V2f865lYfz44YT On March 24, 2024 5:57:01 AM PDT, Tom Forbes wrote: >Hello, >I maintain a small project called gping[1] that recently added support fo= r FreeBSD=2E One of the issues I ran into with running this on FreeBSD was = that the `ping` command seems to disallow intervals of less than 1 second i= f you are not running as root[2]=2E This check was last touched 23 years ag= o and I'm curious as to why this restriction exists? I assume it's from an = earlier time in the internets history, and perhaps is related to potential = misuse of the command to flood targets with packets via ping? > >If it is then I'd like to suggest that this limitation be removed or is r= educed to `0=2E1` seconds instead? Using `ping` for this kind of thing isn'= t a viable attack today, and the 1 second limitation seems like it would ge= t in the way of useful uses of the ping command=2E > >Also this is my first post to any *BSD mailing list, so please let me kno= w if this is not the right place to ask this question or propose this! > >Thanks, >Tom > >1=2E https://github=2Ecom/orf/gping >2=2E https://github=2Ecom/freebsd/freebsd-src/blame/8a56ef8d75b42ee722824= 7466c8c1712de6e3b6f/sbin/ping/ping6=2Ec#L441 Other UNIX-like systems have the same restriction=2E At $JOB we use Solari= s and various Linux systems=2E All maintain the same restriction=2E Other B= SDs are the same=2EI don't think FreeBSD should be an outlier=2E Maybe setgid bit or a capability to remove the restriction may be a bette= r solution=2E But to reduce the timeout to essentially remove it is IMO unw= ise=2E=20 --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD=2Eorg NTP: Web: https://nwtime=2Eorg e^(i*pi)+1=3D0 Pardon the typos=2E Small keyboard in use=2E From nobody Sun Mar 24 15:04:15 2024 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 4V2fVY37zbz5Frp3 for ; Sun, 24 Mar 2024 15:04:37 +0000 (UTC) (envelope-from tom@tomforb.es) Received: from fout6-smtp.messagingengine.com (fout6-smtp.messagingengine.com [103.168.172.149]) (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 4V2fVX5CmKz46WW for ; Sun, 24 Mar 2024 15:04:36 +0000 (UTC) (envelope-from tom@tomforb.es) Authentication-Results: mx1.freebsd.org; none Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id A59631380089; Sun, 24 Mar 2024 11:04:35 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute2.internal (MEProxy); Sun, 24 Mar 2024 11:04:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomforb.es; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1711292675; x=1711379075; bh=eMjwIN+/KU CJqZLkaez4Kf3lKqJs7acGX1bve7Vcuyg=; b=WOIw4i8d32UYa8TTykZfz251a9 5zvT62dlan53Z+QWkUFhNKpXfwSHMJ5GagLZhut770SEfH/OfDLTy3mHvHdbuFbQ 76hxloeiCgiy5AX3hvt5SzLXvuaLRKjxRMGLZPKMgbdEY1YA6PASm1ziG5v7DRQ4 WJn4YMYvwKBGvujge+t0t5kE87+K0bf/GneMTMKZbWICYk5ZfWztiXbXJZEIV1dL ABEfDpGowBQgG0D19+yNjHx6bxdmgZSqQZPuRUBiK9EHpSvNaU3Q7wMEDlZ4oG9c 7OrUnCSg9RTA+eOpb9yntl4ecFBD30OT9BNdNij8YhqdCVo8mLRVVjL9ykFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1711292675; x=1711379075; bh=eMjwIN+/KUCJqZLkaez4Kf3lKqJs 7acGX1bve7Vcuyg=; b=fm04oXseZzwndZvkNW25m7V7MacGg7g4tAXjfUbPIUyh 2JxROXLXbby+2AlcC61BBF1OAsqg+LlBwzPjWKh/6NjwX3BwW3NOl9K8U/nZFxGB Wsdm6+zLU30+cP8kp0lbHEMEWZApmXvv6atj5AIhNtms5U3GKrVtmTTN4x6itPW8 yzeb5h2+QGcxhjMk1Lt0rP7/Eu2NL0DoYE37qH+ccW+/OXdYBJNNd3pAANnqXf/H ZpIlbcxAgtRYKyhQVGaLHLr+JTFmP6dBx4zy9Gl9MUTglkyh38GXy2InT5mDjLmS x38DiSg0URu9r7z8RJH4zgFKdv+7uL/NY4+6GyYEqg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtjedgjeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfvohhm ucfhohhrsggvshdfuceothhomhesthhomhhfohhrsgdrvghsqeenucggtffrrghtthgvrh hnpeejveekffegudfhgeekhfekuedvlefhfffftedujeejhedvheffueehfeehhfeivden ucffohhmrghinhepghhithhhuhgsrdgtohhmpdhfrhgvvggsshgurdhorhhgpdhnfihtih hmvgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehtohhmsehtohhmfhhorhgsrdgvsh X-ME-Proxy: Feedback-ID: i915146fc:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 486A92D4007D; Sun, 24 Mar 2024 11:04:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-332-gdeb4194079-fm-20240319.002-gdeb41940 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 Message-Id: <4f8b035c-b2cc-4606-a691-f1d86827282b@app.fastmail.com> In-Reply-To: <2D5DD001-DD98-4A8E-9458-6754E6D977EE@cschubert.com> References: <954e1d80-d44f-4c3d-88a7-122dc0f25de4@app.fastmail.com> <2D5DD001-DD98-4A8E-9458-6754E6D977EE@cschubert.com> Date: Sun, 24 Mar 2024 15:04:15 +0000 From: "Tom Forbes" To: "Cy Schubert" , freebsd-hackers@freebsd.org Subject: Re: Removing or changing the ping interval restriction for non-root users Content-Type: multipart/alternative; boundary=24f27762460e46539679bef9d11faa60 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US] X-Rspamd-Queue-Id: 4V2fVX5CmKz46WW --24f27762460e46539679bef9d11faa60 Content-Type: text/plain I've personally never come across this limitation on any system that I've used, however it is a good point that there are bound to be systems that have the same limitation. After digging a bit more into the history the limitation was added in this commit[1] in 1998 with the explicit intention to "secure options from user-level D.O.S attacks". A lot of things have changed since 1998, and setting an arbitrary high limit to prevent "ping" and "ping6" from being used to DOS networked devices would be a pretty suspect decision if it was suggested today. I expect a few other distributions have inherited this limit from the original contribution, but to me that doesn't lend a strong argument to keeping it if the underlying reason it exists doesn't make sense anymore _and_ if removing/reducing it is a backwards-compatible, simple and non-invasive change. Tom 1. https://github.com/freebsd/freebsd-src/commit/526f06b278d9252add168aa18b60242c08771165 On Sun, 24 Mar 2024, at 2:48 PM, Cy Schubert wrote: > On March 24, 2024 5:57:01 AM PDT, Tom Forbes wrote: > >Hello, > >I maintain a small project called gping[1] that recently added support for FreeBSD. One of the issues I ran into with running this on FreeBSD was that the `ping` command seems to disallow intervals of less than 1 second if you are not running as root[2]. This check was last touched 23 years ago and I'm curious as to why this restriction exists? I assume it's from an earlier time in the internets history, and perhaps is related to potential misuse of the command to flood targets with packets via ping? > > > >If it is then I'd like to suggest that this limitation be removed or is reduced to `0.1` seconds instead? Using `ping` for this kind of thing isn't a viable attack today, and the 1 second limitation seems like it would get in the way of useful uses of the ping command. > > > >Also this is my first post to any *BSD mailing list, so please let me know if this is not the right place to ask this question or propose this! > > > >Thanks, > >Tom > > > >1. https://github.com/orf/gping > >2. https://github.com/freebsd/freebsd-src/blame/8a56ef8d75b42ee7228247466c8c1712de6e3b6f/sbin/ping/ping6.c#L441 > Other UNIX-like systems have the same restriction. At $JOB we use Solaris and various Linux systems. All maintain the same restriction. Other BSDs are the same.I don't think FreeBSD should be an outlier. > > Maybe setgid bit or a capability to remove the restriction may be a better solution. But to reduce the timeout to essentially remove it is IMO unwise. > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > e^(i*pi)+1=0 > > Pardon the typos. Small keyboard in use. > --24f27762460e46539679bef9d11faa60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I've personally= never come across this limitation on any system that I've used, however= it is a good point that there are bound to be systems that have the sam= e limitation. After digging a bit more into the history the limitation w= as added in this commit[1] in 1998 with the explicit intention to "secur= e options from user-level D.O.S attacks".

A= lot of things have changed since 1998, and setting an arbitrary high li= mit to prevent "ping" and "ping6" from being used to DOS networked devic= es would be a pretty suspect decision if it was suggested today. I expec= t a few other distributions have inherited this limit from the original = contribution, but to me that doesn't lend a strong argument to keeping i= t if the underlying reason it exists doesn't make sense anymore _and_ if= removing/reducing it is a backwards-compatible, simple and non-invasive= change.

Tom
  1. https://github.com/freebsd/freebsd-src/commit/526f06b278d9= 252add168aa18b60242c08771165

On Sun= , 24 Mar 2024, at 2:48 PM, Cy Schubert wrote:
On March 24, 2024 5:57:01 AM PDT, Tom F= orbes <tom@tomforb.es> wrote= :
>Hello,
>I maintain a small project = called gping[1] that recently added support for FreeBSD. One of the issu= es I ran into with running this on FreeBSD was that the `ping` command s= eems to disallow intervals of less than 1 second if you are not running = as root[2]. This check was last touched 23 years ago and I'm curious as = to why this restriction exists? I assume it's from an earlier time in th= e internets history, and perhaps is related to potential misuse of the c= ommand to flood targets with packets via ping?
>
>If it is then I'd like to suggest that this limitation be re= moved or is reduced to `0.1` seconds instead? Using `ping` for this kind= of thing isn't a viable attack today, and the 1 second limitation seems= like it would get in the way of useful uses of the ping command.
>
>Also this is my first post to any *BSD ma= iling list, so please let me know if this is not the right place to ask = this question or propose this!
>
>Than= ks,
>Tom
>
>1. <= a href=3D"https://github.com/orf/gping">https://github.com/orf/gping=
Other UNIX-li= ke systems have the same restriction. At $JOB we use Solaris and various= Linux systems. All maintain the same restriction. Other BSDs are the sa= me.I don't think FreeBSD should be an outlier.

<= div>Maybe  setgid bit or a capability to remove the restriction may= be a better solution. But to reduce the timeout to essentially remove i= t is IMO unwise. 

-- 
Cheers,
FreeBSD UN= IX:  <cy@FreeBSD.org>&n= bsp; Web:  https://FreeBSD.org=
NTP:        &= nbsp;            = <cy@nwtime.org>  &n= bsp; Web:  https://nwtime.org

--24f27762460e46539679bef9d11faa60-- From nobody Sun Mar 24 18:20:36 2024 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 4V2krz0LvNz5GBdv for ; Sun, 24 Mar 2024 18:20:51 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V2krx5KtJz4TlL for ; Sun, 24 Mar 2024 18:20:49 +0000 (UTC) (envelope-from leeb@ratnaling.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ratnaling-org.20230601.gappssmtp.com header.s=20230601 header.b=WrMhzQvq; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=ratnaling.org (policy=none); spf=neutral (mx1.freebsd.org: 2607:f8b0:4864:20::b32 is neither permitted nor denied by domain of leeb@ratnaling.org) smtp.mailfrom=leeb@ratnaling.org Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-dc236729a2bso3502408276.0 for ; Sun, 24 Mar 2024 11:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ratnaling-org.20230601.gappssmtp.com; s=20230601; t=1711304448; x=1711909248; darn=freebsd.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=d2DjWttCyW4tJ5GuV3FOyWpATIRMF258FdpXgPsJFjY=; b=WrMhzQvqv93wG+goOANjB1UzZ6ShJARebVCUlqeGsQ7/ySFikc26jnC59Ch1WzMZGg ODsZBU7XolXlSJySkaw2r+OXJANjGJG8td3nF3eCAs2vHPFSyKpi5oVJSiz0+1211bkY FlcH+rVPRVYGXfYtL1HfX2hDYVoA0DETUxu/2n43jhhZUwaHNok4ACoUvrx5TKPN7HaL kxkIiLxV2zl+hI2e5W3uaH/yRWpIJ1hRdgoRdb5ZKEANLv6uH6ej4Loat3X69kMKRsHB jBy8VIP3JO9CPF5CHAF+A1UB8BbvZpHM6MH9j+ioH7UPOOCdbO1phAI7tFqb7qoLs6h4 yblg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711304448; x=1711909248; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d2DjWttCyW4tJ5GuV3FOyWpATIRMF258FdpXgPsJFjY=; b=TcLSTbCPyh1uNnB/KYkiBzvVj0FA1328zOersY2ySCK49veJnqy15ucALClvbJMZmI la0D5bZacczu1v9tl0PNZOKijAGqMEXEfK66xGxNo+R1jF2qG5jIKMx/TYsfgdpbbkEm WyNfj57GmJceUe50hTJlqYVfUmhe9weXQxc3cDz+XPgKSfAxAZQIYvXnxi7C3CfSpI0f qVIc7ZjvKBxjx2F6dsUqY/Ca8DCAnPeevuCXdVUtC0/QSyyg6MfKDspM8iwZw9NllkDk 2HVWJpJ3GfJWkDARQ6FP4Y3hvVfwzvSo67Fg2FCZVAHI1Yg4rD7enCvHaXiKnGyfhsqp HD4Q== X-Gm-Message-State: AOJu0Yw4dkfU3lGN07GG5YUIKkLHHI7+SxwgOFXm0I1iUnGdYO7/Sd9v /6uNloHh+DJ0r2/4Z+P6kuwIux3ldgQF/6KTw5rtPliPy/kpjYyScRIcYBghfl9hJD9z2uMt4ki 6MrtnSPjPVBpnUxtstsMr9kiK7OZ25kvk51FFs1dMbHJYfeOjrSs= X-Google-Smtp-Source: AGHT+IHaWZz3dvafY7usIh3TZHhwZiqDDqz0mUswX6cDEvbLbaRDn/6N141ZVoVJBVNCW+l/jLtY4am3FteEiAXnEBs= X-Received: by 2002:a25:4982:0:b0:dcd:5bdb:4aa4 with SMTP id w124-20020a254982000000b00dcd5bdb4aa4mr3658261yba.51.1711304448196; Sun, 24 Mar 2024 11:20:48 -0700 (PDT) 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 References: <954e1d80-d44f-4c3d-88a7-122dc0f25de4@app.fastmail.com> <2D5DD001-DD98-4A8E-9458-6754E6D977EE@cschubert.com> <4f8b035c-b2cc-4606-a691-f1d86827282b@app.fastmail.com> In-Reply-To: <4f8b035c-b2cc-4606-a691-f1d86827282b@app.fastmail.com> From: Lee Brown Date: Sun, 24 Mar 2024 11:20:36 -0700 Message-ID: Subject: Re: Removing or changing the ping interval restriction for non-root users To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000bce2b106146c1de0" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[ratnaling-org.20230601.gappssmtp.com:s=20230601]; DMARC_POLICY_SOFTFAIL(0.10)[ratnaling.org : No valid SPF, DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; R_SPF_NEUTRAL(0.00)[?all]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b32:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[ratnaling-org.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4V2krx5KtJz4TlL --000000000000bce2b106146c1de0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable net/fping will allow sub-second intervals: $ ping -i .1 10.1.1.1 ping: -i interval too short: Operation not permitted $ fping --interval=3D1 --vcount=3D20 --period=3D50 10.1.1.1 20 lines of result Better than changing base IMHO (POLA) On Sun, Mar 24, 2024 at 8:04=E2=80=AFAM Tom Forbes wrote: > I've personally never come across this limitation on any system that I've > used, however it is a good point that there are bound to be systems that > have the same limitation. After digging a bit more into the history the > limitation was added in this commit[1] in 1998 with the explicit intentio= n > to "secure options from user-level D.O.S attacks". > > A lot of things have changed since 1998, and setting an arbitrary high > limit to prevent "ping" and "ping6" from being used to DOS networked > devices would be a pretty suspect decision if it was suggested today. I > expect a few other distributions have inherited this limit from the > original contribution, but to me that doesn't lend a strong argument to > keeping it if the underlying reason it exists doesn't make sense anymore > _and_ if removing/reducing it is a backwards-compatible, simple and > non-invasive change. > > Tom > > 1. > https://github.com/freebsd/freebsd-src/commit/526f06b278d9252add168aa1= 8b60242c08771165 > > > On Sun, 24 Mar 2024, at 2:48 PM, Cy Schubert wrote: > > On March 24, 2024 5:57:01 AM PDT, Tom Forbes wrote: > >Hello, > >I maintain a small project called gping[1] that recently added support > for FreeBSD. One of the issues I ran into with running this on FreeBSD wa= s > that the `ping` command seems to disallow intervals of less than 1 second > if you are not running as root[2]. This check was last touched 23 years a= go > and I'm curious as to why this restriction exists? I assume it's from an > earlier time in the internets history, and perhaps is related to potentia= l > misuse of the command to flood targets with packets via ping? > > > >If it is then I'd like to suggest that this limitation be removed or is > reduced to `0.1` seconds instead? Using `ping` for this kind of thing isn= 't > a viable attack today, and the 1 second limitation seems like it would ge= t > in the way of useful uses of the ping command. > > > >Also this is my first post to any *BSD mailing list, so please let me > know if this is not the right place to ask this question or propose this! > > > >Thanks, > >Tom > > > >1. https://github.com/orf/gping > >2. > https://github.com/freebsd/freebsd-src/blame/8a56ef8d75b42ee7228247466c8c= 1712de6e3b6f/sbin/ping/ping6.c#L441 > Other UNIX-like systems have the same restriction. At $JOB we use Solaris > and various Linux systems. All maintain the same restriction. Other BSDs > are the same.I don't think FreeBSD should be an outlier. > > Maybe setgid bit or a capability to remove the restriction may be a > better solution. But to reduce the timeout to essentially remove it is IM= O > unwise. > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > e^(i*pi)+1=3D0 > > Pardon the typos. Small keyboard in use. > > > --000000000000bce2b106146c1de0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
net/fping will allow sub-second intervals:
=
$ ping -i .1 10.1.1.1
ping: -i interval too short: Operation = not permitted

$ fping --interval=3D1 --vcount=3D20= --period=3D50 10.1.1.1
20 lines of result

Better than changing base IMHO (POLA)

On Sun, Mar 24, 2024 at 8= :04=E2=80=AFAM Tom Forbes <tom@tomforb= .es> wrote:
I've persona= lly never come across this limitation on any system that I've used, how= ever it is a good point that there are bound to be systems that have the sa= me limitation. After digging a bit more into the history the limitation was= added in this commit[1] in 1998 with the explicit intention to "secur= e options from user-level D.O.S attacks".

A lot of things have changed since 1998, and setting an arbitrary high lim= it to prevent "ping" and "ping6" from being used to DOS= networked devices would be a pretty suspect decision if it was suggested t= oday. I expect a few other distributions have inherited this limit from the= original contribution, but to me that doesn't lend a strong argument t= o keeping it if the underlying reason it exists doesn't make sense anym= ore _and_ if removing/reducing it is a backwards-compatible, simple and non= -invasive change.

Tom
  1. https://github.com/freebsd/freebsd-src/c= ommit/526f06b278d9252add168aa18b60242c08771165

On Sun, 24 Mar 2024, at 2:48 PM, Cy Schubert wrote:
On March 24, 2024= 5:57:01 AM PDT, Tom Forbes <tom@tomforb.es> wrote:
>Hello,
>I maintain a small project called gping[1] that recently added suppo= rt for FreeBSD. One of the issues I ran into with running this on FreeBSD w= as that the `ping` command seems to disallow intervals of less than 1 secon= d if you are not running as root[2]. This check was last touched 23 years a= go and I'm curious as to why this restriction exists? I assume it's= from an earlier time in the internets history, and perhaps is related to p= otential misuse of the command to flood targets with packets via ping?
<= /div>
>
>If it is then I'd like to suggest that= this limitation be removed or is reduced to `0.1` seconds instead? Using `= ping` for this kind of thing isn't a viable attack today, and the 1 sec= ond limitation seems like it would get in the way of useful uses of the pin= g command.
>
>Also this is my first post = to any *BSD mailing list, so please let me know if this is not the right pl= ace to ask this question or propose this!
>
= >Thanks,
>Tom
>
Other UNIX-like systems have the same restriction. At $JOB w= e use Solaris and various Linux systems. All maintain the same restriction.= Other BSDs are the same.I don't think FreeBSD should be an outlier.

Maybe=C2=A0 setgid bit or a capability to remove= the restriction may be a better solution. But to reduce the timeout to ess= entially remove it is IMO unwise.=C2=A0

--=C2= =A0
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com&g= t;
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 Web:=C2=A0=C2=A0https://FreeBSD.org
NTP:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <cy@nwtime.org>=C2=A0=C2=A0=C2=A0 Web= :=C2=A0=C2=A0https://nwtim= e.org
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 e^(i*pi)+1=3D0

= Pardon the typos. Small keyboard in use.


--000000000000bce2b106146c1de0--