From nobody Mon Sep 6 06:49:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EA10217B9318 for ; Mon, 6 Sep 2021 06:49:54 +0000 (UTC) (envelope-from khng300@gmail.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H2zXy5bTyz4dkX; Mon, 6 Sep 2021 06:49:54 +0000 (UTC) (envelope-from khng300@gmail.com) Received: by mail-pj1-x1035.google.com with SMTP id c6so3685981pjv.1; Sun, 05 Sep 2021 23:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yb5+XaDKiFWFB4XECqBUxAjt8TdsCBJLNyIhjs3qm4o=; b=Y4xVBCO1LD+x++zgeob21F6G5/5qR+EEZERVnYDE/9MwSz9LLMDzzhg2oEDHoHLdtL oRZJa6/4XgeJBNxwtml//Wvx2F/pihmSiYAusxjp98vYPTivhEfxi94ULvf3CU7Ran+S JhuTsgiT+B0VUmgCL6ck5God9Pf6JHtKtmxDYwsktO/NQ80fJjwLcEM13cjr/dqGBuRY wrEY4bWlqrHIbYEcqYZqi8gGcSD09M2cmVbtnFPqVSoVmBCn/Qa7fZFFhDR1Ek1FLtRd XEI9E63hxhq48qfCZVm+C32eU+gWYTwAuZaFO3VECq/Q7imIwov3us79eoPro6aNJOoA mVkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yb5+XaDKiFWFB4XECqBUxAjt8TdsCBJLNyIhjs3qm4o=; b=Rrz8xV16SoAZNVZj1VBfi2XLuyEXkRyBrL74SGEsfB5CpPBZuDx/9LwxvBqtFizwky k1ooAoH9d7KSiPzhcI9R/s/tnRNVq6P1FygLcQ+BfeCOwDjNNLbsEOZZHxx5L+09pI8W YlxPFIWrPb8BV2b6pXEnyDdv9mHInGpFbfWU53uWik/EOyL+L/E78QUTPdEVwEVKin97 eYwU402tudMj58sLQUlC3EZs8OVUAeHQgwpex72rCi6lgIMvVwy2FyVfBgG+4ZZzzejm MYvJg+l5SNakY0cJwtk6q+FtUXmTibC5NtaJGT7aXOC511Vf5Qm8Gzwx/7rNmXcgaWfR ZRRA== X-Gm-Message-State: AOAM530T1GhqUqrJam7IUVzEuZJ04JBQU259IFiBSY3W5FvdQdf226HQ BtmPmWw9B0415Mm9JD+EM8ivPk54sJX05qXy X-Google-Smtp-Source: ABdhPJwFuRP8b+7WqElSlp4wyf0/tSV9eyi/22CVCdZ8+aIxLrMatqyOsWcnKP4EDRN4gMoIOGe/zw== X-Received: by 2002:a17:90a:d712:: with SMTP id y18mr12511229pju.37.1630910993217; Sun, 05 Sep 2021 23:49:53 -0700 (PDT) Received: from dac1f024b.dhcp.in.dimsumlabs.com (n219076164042.netvigator.com. [219.76.164.42]) by smtp.gmail.com with ESMTPSA id n11sm6628488pjh.23.2021.09.05.23.49.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Sep 2021 23:49:52 -0700 (PDT) Subject: Re: Solaris doors implementation To: =?UTF-8?Q?Bojan_Novkovi=c4=87?= , "debdrup@freebsd.org" , "gbe@freebsd.org" Cc: "freebsd-hackers@freebsd.org" References: <0c506180-47e5-7dcc-7799-40dc0d4f46cb@gmail.com> From: Ka Ho Ng Message-ID: <172047d2-8429-3bbe-9966-64dad1914990@gmail.com> Date: Mon, 6 Sep 2021 14:49:49 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4H2zXy5bTyz4dkX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2021/9/6 4:15 AM, Bojan Novkovi wrote: > Hello, > > Thank you for your quick response and willingness to help. > Initially I just wanted to find if anybody was working on this and possibly help them. > However, since nobody is working on this, I have started writing > a cleanroom implementation using the Illumos code as reference. > I will be in touch via IRC should any major issues arise. > Thank you once again! > > Bojan Novkovi > > ________________________________ > From: Ka Ho Ng > Sent: Saturday, September 4, 2021 11:40 PM > To: Gordon Bergling ; Bojan Novkovi > Cc: freebsd-hackers@freebsd.org > Subject: Re: Solaris doors implementation > > On 2021/9/5 5:02 PM, Gordon Bergling wrote: >> Hi Bojan, >> >> On Sat, Sep 04, 2021 at 07:59:56PM +0000, Bojan Novkovi wrote: >>> Hello! >>> >>> I am interested in helping with the Solaris doors IPC implementation idea posted on the IdeasPage. >>> However, seeing as there is no contact listed, would anyone know if this idea is being worked on and who the technical contact is? >>> >>> Kind regards, >>> Bojan Novkovic >> >> I don't know the technical contact, but regarding the doors implementation, >> you could look at the OpenSolaris / Illumos implementation [1]. >> >> Since we already have CDDL sources imported, a port of the original >> implementation would be easier compared to a clean room implementation. >> >> --Gordon >> >> [1] https://github.com/illumos/illumos-gate >> > > I believe we still need a clean room implementation if we want the IPC > subsystem to be better integrated. > > Ka Ho > Feel free to put up a differential if you think it is ready. :) Ka Ho From nobody Mon Sep 6 16:36:16 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5828017AC300 for ; Mon, 6 Sep 2021 16:36:29 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H3DYm3W8Jz56ss; Mon, 6 Sep 2021 16:36:28 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 186GaGGD009704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Sep 2021 12:36:21 -0400 Date: Mon, 6 Sep 2021 09:36:16 -0700 From: Benjamin Kaduk To: Ed Maste Cc: FreeBSD Hackers Subject: Re: OpenSSH 8.7p1 update for the base system Message-ID: <20210906163616.GI96301@kduck.mit.edu> References: <20210905040341.GG96301@kduck.mit.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4H3DYm3W8Jz56ss X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-3.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[mit.edu]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.11:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.992]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Sun, Sep 05, 2021 at 10:42:45AM -0400, Ed Maste wrote: > On Sun, 5 Sept 2021 at 00:04, Benjamin Kaduk wrote: > > > > Hi Ed, > > > > I'm not sure whether this would be something for the release notes or not, > > but I believe that making privilege separation mandatory causes GSSAPI > > credential delegation to essentially not work. > > I think privilege separation became mandatory in 7.5p1, imported in > d93a896ef959 in 2017. Thus I believe this hasn't been functional for > quite some time; am I mistaken? That seems likely; I confess I didn't follow the versioning very closely across which machines I have to use a workaround on. > It should still be documented, even if it's well after the fact. I > think it's also worth trying to fix, although I'm not sure if I will > have time to work on it. Fair enough. I don't remember enough about what channels are available for communicating (sensitive!) information across the UID boundary in sshd, so I can't really speak to how hard it would be. Thanks, Ben From nobody Mon Sep 6 17:16:04 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E4EF417AA2B4; Mon, 6 Sep 2021 17:15:49 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 4H3FR91smjz3Qfg; Mon, 6 Sep 2021 17:15:49 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id BB3F4132F; Mon, 6 Sep 2021 17:15:48 +0000 (UTC) Subject: Re: PAM module for loading ZFS keys on login To: freebsd-current@freebsd.org, Greg , FreeBSD Hackers References: <67F44CFE-2496-4B13-8583-8A80D9ED3A4A@unrelenting.technology> <20210906140137.iGt2J%steffen@sdaoden.eu> From: Eric McCorkle Message-ID: Date: Mon, 6 Sep 2021 13:16:04 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20210906140137.iGt2J%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4H3FR91smjz3Qfg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 2001:470:1f11:617::107) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-0.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[eric]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[metricspace.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Honestly, I think the best approach to this is the autounmountd unload keys thing. There's just too many ways the sessions thing can go wrong. The autounmountd solution gets the job done, and it tolerates possible failures better than anything else I can think of, barring some kind of major kernel-side awareness of sessions. There's potentially a gap between the user logging out and the keys being unloaded, but that's not much of a problem when you consider the most likely use case. The thing to keep in mind with the primary use case I've suggested for the ZFS key load/unload stuff is that it's not so much about preventing the Adversary from gaining access to data is it is about constraining when they need to be active to pull off an exfiltration. This is the real reason you see it on secure systems: it makes the Adversary's job a lot harder, while at the same time making the jobs of defensive ops and DFIR folks a whole lot easier. Say I've got sensitive files in my home directory. On a base system, the Adversary just has to circumvent OS file protections, but they can do this at any time. This means your DFIR folks have to dig through a huge amount of history. If I have to be logged in for the keys to be present, then the Adversary has to have some kind of monitoring to detect when I am, and then has a constrained window in which to pull off the attack. Both of these increase the likelihood of detection, while also constraining the window of time the DFIR folks have to examine. This isn't changed much by having the system wait some small time interval after I'm logged out to unmount my home directory and unload my keys. (If anything, it introduces another potential vector for detection: the unmounting/unloading will fail if someone is still accessing my data after I'm gone.) On 9/6/21 10:01 AM, Steffen Nurpmeso wrote: > Eric McCorkle wrote in > : > |Interesting, I wasn't aware of the upstream module. I'd say that's > > It's existence was the reason i have readded (now optional, and > a tad different) session support for my pam_xdg PAM module, > because i was thinking that, if such a many-eyes-seen thing of > a software project that claims to be and aims at being enterprise, > ships such a terrible and terribly broken thing, then i can also > offer session tracking. But my manual at least states > > CAVEATS > On Unix systems any “daemonized” program or script is reparented to the > program running with PID 1, most likely leaving the PAM user session > without PAM recognizing this. Yet careless such code may hold or expect > availability of resources of the session it just left, truly performing > cleanup when sessions end seems thus unwise. Since so many PAM modules > do support session tracking and cleanup pam_xdg.so readded optional sup‐ > port for this. > > But the real solution would be PAM session tracking in-kernel, > somehow, wouldn't it? > Also, on FreeBSD and OpenPAM many separate files exist in > /etc/pam.d for things which might open a session, whereas linuxpam > at least has /etc/pam.d/common-session; it has many common- things > in fact, and in /etc/pam.d/sshd i for example see > > # > # /etc/pam.d/sshd - openssh service module configuration > # > > auth include common-auth > > account include common-account > > password include common-password > > session include common-session > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > From nobody Mon Sep 6 21:44:18 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3232017A532B; Mon, 6 Sep 2021 21:44:09 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (static-74-106-232-4.bltmmd.fios.verizon.net [74.106.232.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4H3MNm3cKLz3HZN; Mon, 6 Sep 2021 21:44:08 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 5062912FB; Mon, 6 Sep 2021 21:44:02 +0000 (UTC) Subject: Re: PAM module for loading ZFS keys on login To: freebsd-current@freebsd.org, Greg , FreeBSD Hackers References: <67F44CFE-2496-4B13-8583-8A80D9ED3A4A@unrelenting.technology> <20210906140137.iGt2J%steffen@sdaoden.eu> <20210906185354.D5ymE%steffen@sdaoden.eu> From: Eric McCorkle Message-ID: <61e11d16-17d2-5f5e-a02a-ba1f1b56bbc7@metricspace.net> Date: Mon, 6 Sep 2021 17:44:18 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20210906185354.D5ymE%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H3MNm3cKLz3HZN X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eric@metricspace.net has no SPF policy when checking 74.106.232.4) smtp.mailfrom=eric@metricspace.net X-Spamd-Result: default: False [-0.32 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[eric]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[metricspace.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.68)[0.680]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.106.224.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I looked at the upstream one too. Mine is simple because I modified libzfs to be able to take the key directly in the key location override argument. If you look at my patch, it adds a "direct" key location, which basically works like "direct:keydata", where "keydata" is your key. In the case of the PAM module, this ends up being "direct:password". It looks like they essentially pull in all the libzfs logic for preparing keys. If you notice, they go directly to lzc_load_key (that is basically a thin wrapper around the ioctl). It's worth noting that apparently they change the key to the dataset when the user changes their password. Anyway, I've seen enough. I'm going to abandon the review for my PAM module and use the upstream one. I'm going to keep the review for the autounmountd patch live, though. On 9/6/21 2:53 PM, Steffen Nurpmeso wrote: > Eric McCorkle wrote in > : > ... > >> This patch creates a new PAM module that will load a ZFS key upon a > >> successful login: https://reviews.freebsd.org/D31844. It will use the > >> user's auth token as the key argument to loading a ZFS encryption key on > >> a user-specific ZFS data set. > ... > > Without knowing about libzfs i personally was stunned about the > simplicity of your patch, having read the upstream one. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > From nobody Tue Sep 7 02:10:34 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 75F0D17B609D; Tue, 7 Sep 2021 02:10:39 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H3TJG1h5nz3vDj; Tue, 7 Sep 2021 02:10:38 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lj1-x229.google.com with SMTP id i28so14030485ljm.7; Mon, 06 Sep 2021 19:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TcRDj/pZZjF5iUzB75eKnPaSQDJbMG4vzUgbNrAB840=; b=AsWDP4bcPXb7r4IhS2RSTMurT97ONuOZw0Lq/ns1dcUohKgzjMzlA4vRiJuNzn2Nwc OGTuThN3XIxSST81pybaHOHMO0ob3pHYyjsbfv0C4zH8pNkjGYujbY6dY/QBttgKar3H sujmfzciqWdr9u0DupBY2gyItnm2YGC/by2BTtpUaNRPxzva3evZV7qKPVIu4vWLNxQ7 NaX09SKYN/we4cXcnA5OHuwoIa8xaXxLcV2r5Ii7173WPi031klyuIx8cgp7SXbFqnA7 I8lvOVG7Fhn0Cy/w8kQIRG+21GqffmJ92Ee627h88fV+Zwr0Ep/drtlFuTFYnP1kWadZ h92g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TcRDj/pZZjF5iUzB75eKnPaSQDJbMG4vzUgbNrAB840=; b=ZupdL7d+QnQHG8nb7mCroYhDrTa9INWyOkkjTMQSOcofv9AWpTO8TjyDZ9FFMw8cpz n8qzzv+vY3dZAfJO7IFUHRKPlFkya0OquLnOi0NHgYsmvHnNld9RY8HZ0OKkUBw/9+Uj O3mnLEuMluEeAtsW4CIKxOPAPziA5fWR1EVDX8Pb745I8gfWjB4sClWjbQ5zM6D9tA4r sMUvAyP3py18XBBjMqpmdjFdIbEobuu1tSRjPmmc0NcMATQLthwHGpRp+Rl6EMDjlGWW 66Q94mlSICTPxY899xCYDUGUjldnP+pdvSRFqER2BsqZ1a8NUpaZrAWvIgYuiZ7DNdUc tG7g== X-Gm-Message-State: AOAM533l+qLyJmT2Y9kitTCw6ST3jjYpxrcRQHurpHY9t1sPg9k4OaY+ fceJYxjOTx3GbpUr4xflSKo= X-Google-Smtp-Source: ABdhPJy3yYLFqLmV6iHUS0FVjKiDcUjOJFpSp5LgJg/ncKbEziRhM+5tBgqZTIYMhPrbso56jIA5eg== X-Received: by 2002:a2e:9e4c:: with SMTP id g12mr12629407ljk.433.1630980636539; Mon, 06 Sep 2021 19:10:36 -0700 (PDT) Received: from rimwks.local ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id a27sm871266lfi.27.2021.09.06.19.10.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Sep 2021 19:10:36 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Tue, 7 Sep 2021 05:10:34 +0300 To: Michael Tuexen Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: TCP connection ignore RST Message-ID: <20210907051034.5669a02d@rimwks.local> In-Reply-To: <927CA9E9-AB74-443D-83A7-931325DB7686@lurchi.franken.de> References: <20210904023730.5eddd6fd@rimwks.local> <927CA9E9-AB74-443D-83A7-931325DB7686@lurchi.franken.de> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4H3TJG1h5nz3vDj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=AsWDP4bc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::229 as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::229:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Sat, 4 Sep 2021 13:19:52 +0200 Michael Tuexen wrote: > > On 4. Sep 2021, at 01:37, Rozhuk Ivan wrote: > >=20 > > Hi! > >=20 > >=20 > > I have strange case: FreeBSD 12.2 ignore TCP RST from windows host > > and continue retransmitting packets. sockstat show that socket > > connected even after many tcp rst packets received. > >=20 > > Any ideas how to fix it? =20 > Where is the trace taken? On the Windows side or on the FreeBSD side > or somewhere else? Could you provide the .pcap file? >=20 =46rom FreeBSD side. https://reviews.freebsd.org/D28142 e82353f84c58da9a5c38bd471a09936c16a5b6ea https://reviews.freebsd.org/D28143 d05d908d6d3c85479c84c707f931148439ae826b sysctl net.inet.tcp.tolerate_missing_ts=3D1 this fixes issue for me. From nobody Tue Sep 7 09:47:30 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 663A217AEDC5; Tue, 7 Sep 2021 09:47:35 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H3gRW191Rz3FHT; Tue, 7 Sep 2021 09:47:35 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf1-x12a.google.com with SMTP id h16so18346210lfk.10; Tue, 07 Sep 2021 02:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=c0Ug/ycyNAh5YDjI3m6iA2hoblDyB7rSXq1PUxtVvrY=; b=RngwoCd/9cW+FyaDI4RwMEQlq7yCP4a2oAh43wTIgpAGEWRz/umPkPWc48VtGzkaUT iEme54TgRiD1G7CsZdTsfMpVYhsjBIPiM48aL0WRqN6eoSb+IDj9tdQfe2JfJmJFRgso YfaVHW80Ptdi1jFLONHIPDz7/QqCqPE+Fzuh7DIyPmKMYxbsmjltjDpzw1e6a5ZYNt9c RiSiBgb9tbDRCbDis8JImWAZDlQillirxnzPo0Hkq3uqffJYW/GZcv9YEw2DKB5uuWPR I+KS1BjYaCuwFssJuvP5FH43d/IrZGeRPOOcNHpJL5OKBJlVCdV0UZykryqOcABiD7Wa TwMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=c0Ug/ycyNAh5YDjI3m6iA2hoblDyB7rSXq1PUxtVvrY=; b=ii4h0DRVOrUSFTEiJZZL5cFuWz9q9vLmCeZW0XGVtb4HP8f5bCkBcDEKWE0J2yq4zj UJzkHwtxRcT8ZnoJq60wwhSGSUGLWnbLrWuCEc8QvhuzhFFCLjyeBKtZDQXofQReNqlY 6XmorH4Q0BqQ25e3MD3VfKm/SRzkd3rqXdhCcfKvDePUjmGok7qjEdQFvmhUSgMez/7K XppJoYnR1UgaWa5hd7iUpfP+U84cEJsq6lY12QGf0Eyi+V47cFW4su2F/pBB3vkqrQ9Q MSgYcjhc2cUbVRJ2cuyGeW33+UUPUBG8+INRA4MQR8eHjFaJOUMDVlJfLJsUkcQi4xj+ AQDQ== X-Gm-Message-State: AOAM530AZcV3/DjOLenMBtDDCaWh1VMRl/eJHdjl9lGoBPYkVj6LEyaS CQgMrSL5JDd7Z4DqBiQzlaigHhK7nBs= X-Google-Smtp-Source: ABdhPJyKmYiUkWn9raJzqsqKAhWFyvy1WbZl0iWpYQI+JuZTcXy8F2zNghtqT+5aHgH7y1A+NJDnlA== X-Received: by 2002:a05:6512:3b12:: with SMTP id f18mr11644108lfv.423.1631008053578; Tue, 07 Sep 2021 02:47:33 -0700 (PDT) Received: from rimwks.local ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id m19sm958429lfu.1.2021.09.07.02.47.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Sep 2021 02:47:33 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Tue, 7 Sep 2021 12:47:30 +0300 To: Michael Tuexen Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: TCP connection ignore RST Message-ID: <20210907124730.7a4a3b9a@rimwks.local> In-Reply-To: <1804249E-FD55-4A4A-9895-BCEDF2323137@lurchi.franken.de> References: <20210904023730.5eddd6fd@rimwks.local> <927CA9E9-AB74-443D-83A7-931325DB7686@lurchi.franken.de> <20210907051034.5669a02d@rimwks.local> <1804249E-FD55-4A4A-9895-BCEDF2323137@lurchi.franken.de> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4H3gRW191Rz3FHT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 7 Sep 2021 10:47:01 +0200 Michael Tuexen wrote: > >>> I have strange case: FreeBSD 12.2 ignore TCP RST from windows host > >>> and continue retransmitting packets. sockstat show that socket > >>> connected even after many tcp rst packets received. > >>> > >>> Any ideas how to fix it? > >> Where is the trace taken? On the Windows side or on the FreeBSD > >> side or somewhere else? Could you provide the .pcap file? > >> > > > > From FreeBSD side. > > > > https://reviews.freebsd.org/D28142 > > e82353f84c58da9a5c38bd471a09936c16a5b6ea > > https://reviews.freebsd.org/D28143 > > d05d908d6d3c85479c84c707f931148439ae826b sysctl > > net.inet.tcp.tolerate_missing_ts=1 this fixes issue for me. > That was my first guess, but after double checking, this code is not > present in FreeBSD 12.2. However, it is present in stable/12. > So could it be that you are using stable/12 and not 12.2? > System build from: commit 8c01699f9194cfa3805ac734ae912529a10c063a CommitDate: Wed Jan 20 14:40:13 2021 +0100 Add some examples to script.1... It is not "clean" 12.2, and it is a bit early than commits with fixes. From nobody Mon Sep 6 18:53:54 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AFC2017BC8C2; Tue, 7 Sep 2021 11:29:16 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H3jhr3s9yz4X2l; Tue, 7 Sep 2021 11:29:16 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id A980F1605B; Mon, 6 Sep 2021 20:53:56 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 8CC13F98; Mon, 6 Sep 2021 20:53:54 +0200 (CEST) Date: Mon, 06 Sep 2021 20:53:54 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Eric McCorkle Cc: freebsd-current@freebsd.org, Greg , FreeBSD Hackers Subject: Re: PAM module for loading ZFS keys on login Message-ID: <20210906185354.D5ymE%steffen@sdaoden.eu> In-Reply-To: References: <67F44CFE-2496-4B13-8583-8A80D9ED3A4A@unrelenting.technology> <20210906140137.iGt2J%steffen@sdaoden.eu> Mail-Followup-To: Eric McCorkle , freebsd-current@freebsd.org, Greg , FreeBSD Hackers User-Agent: s-nail v14.9.22-175-gc118a4a5c7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4H3jhr3s9yz4X2l X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N 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 Eric McCorkle wrote in : ... >> This patch creates a new PAM module that will load a ZFS key upon a >> successful login: https://reviews.freebsd.org/D31844. It will use the >> user's auth token as the key argument to loading a ZFS encryption key on >> a user-specific ZFS data set. ... Without knowing about libzfs i personally was stunned about the simplicity of your patch, having read the upstream one. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Sep 6 14:01:37 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3FB6917BCB87; Tue, 7 Sep 2021 11:29:17 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H3jhr3k8bz4X5P; Tue, 7 Sep 2021 11:29:16 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 7B9C716056; Mon, 6 Sep 2021 16:01:39 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 8D281F7B; Mon, 6 Sep 2021 16:01:37 +0200 (CEST) Date: Mon, 06 Sep 2021 16:01:37 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: freebsd-current@freebsd.org Cc: Eric McCorkle , Greg , FreeBSD Hackers Subject: Re: PAM module for loading ZFS keys on login Message-ID: <20210906140137.iGt2J%steffen@sdaoden.eu> In-Reply-To: References: <67F44CFE-2496-4B13-8583-8A80D9ED3A4A@unrelenting.technology> Mail-Followup-To: freebsd-current@freebsd.org, Eric McCorkle , Greg , FreeBSD Hackers User-Agent: s-nail v14.9.22-175-gc118a4a5c7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. 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-Rspamd-Queue-Id: 4H3jhr3k8bz4X5P X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_CONTAINS_FROM(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Eric McCorkle wrote in : |Interesting, I wasn't aware of the upstream module. I'd say that's It's existence was the reason i have readded (now optional, and a tad different) session support for my pam_xdg PAM module, because i was thinking that, if such a many-eyes-seen thing of a software project that claims to be and aims at being enterprise, ships such a terrible and terribly broken thing, then i can also offer session tracking. But my manual at least states CAVEATS On Unix systems any =E2=80=9Cdaemonized=E2=80=9D program or script i= s reparented to the program running with PID 1, most likely leaving the PAM user session without PAM recognizing this. Yet careless such code may hold or ex= pect availability of resources of the session it just left, truly perform= ing cleanup when sessions end seems thus unwise. Since so many PAM modu= les do support session tracking and cleanup pam_xdg.so readded optional = sup=E2=80=90 port for this. But the real solution would be PAM session tracking in-kernel, somehow, wouldn't it? Also, on FreeBSD and OpenPAM many separate files exist in /etc/pam.d for things which might open a session, whereas linuxpam at least has /etc/pam.d/common-session; it has many common- things in fact, and in /etc/pam.d/sshd i for example see # # /etc/pam.d/sshd - openssh service module configuration # auth include common-auth account include common-account password include common-password session include common-session --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Tue Sep 7 11:37:44 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6211517C1B4E; Tue, 7 Sep 2021 11:37:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H3jtt0Fv6z4cyC; Tue, 7 Sep 2021 11:37:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 187Bbinv033457 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 7 Sep 2021 14:37:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 187Bbinv033457 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 187Bbiin033455; Tue, 7 Sep 2021 14:37:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 Sep 2021 14:37:44 +0300 From: Konstantin Belousov To: freebsd-current@freebsd.org, FreeBSD Hackers Subject: Re: PAM module for loading ZFS keys on login Message-ID: References: <67F44CFE-2496-4B13-8583-8A80D9ED3A4A@unrelenting.technology> <20210906140137.iGt2J%steffen@sdaoden.eu> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210906140137.iGt2J%steffen@sdaoden.eu> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4H3jtt0Fv6z4cyC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.40 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_SHORT(0.59)[0.590]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Mon, Sep 06, 2021 at 04:01:37PM +0200, Steffen Nurpmeso wrote: > Eric McCorkle wrote in > : > |Interesting, I wasn't aware of the upstream module. I'd say that's > > It's existence was the reason i have readded (now optional, and > a tad different) session support for my pam_xdg PAM module, > because i was thinking that, if such a many-eyes-seen thing of > a software project that claims to be and aims at being enterprise, > ships such a terrible and terribly broken thing, then i can also > offer session tracking. But my manual at least states > > CAVEATS > On Unix systems any “daemonized” program or script is reparented to the > program running with PID 1, most likely leaving the PAM user session > without PAM recognizing this. Yet careless such code may hold or expect > availability of resources of the session it just left, truly performing > cleanup when sessions end seems thus unwise. Since so many PAM modules > do support session tracking and cleanup pam_xdg.so readded optional sup‐ > port for this. If you use reaper facility, that would ensure that all (grand-)children of your session are always reparented to the reaper and not to init. In other words, you can reliable know when the session ends. See procctl(2) PROC_REAP_* commands. I believe that reaper-like functionality is available on all current Unix-like systems, even if under different names. > > But the real solution would be PAM session tracking in-kernel, > somehow, wouldn't it? > Also, on FreeBSD and OpenPAM many separate files exist in > /etc/pam.d for things which might open a session, whereas linuxpam > at least has /etc/pam.d/common-session; it has many common- things > in fact, and in /etc/pam.d/sshd i for example see > > # > # /etc/pam.d/sshd - openssh service module configuration > # > > auth include common-auth > > account include common-account > > password include common-password > > session include common-session > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > From nobody Tue Sep 7 12:30:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2112B17AD923; Tue, 7 Sep 2021 12:30:13 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H3l386TDbz3Klk; Tue, 7 Sep 2021 12:30:12 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id B027716056; Tue, 7 Sep 2021 14:30:11 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 28864FB1; Tue, 7 Sep 2021 14:30:10 +0200 (CEST) Date: Tue, 07 Sep 2021 14:30:10 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Konstantin Belousov Cc: freebsd-current@freebsd.org, FreeBSD Hackers Subject: Re: PAM module for loading ZFS keys on login Message-ID: <20210907123010.iuiKD%steffen@sdaoden.eu> In-Reply-To: References: <67F44CFE-2496-4B13-8583-8A80D9ED3A4A@unrelenting.technology> <20210906140137.iGt2J%steffen@sdaoden.eu> Mail-Followup-To: Konstantin Belousov , freebsd-current@freebsd.org, FreeBSD Hackers User-Agent: s-nail v14.9.22-175-gc118a4a5c7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. 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-Rspamd-Queue-Id: 4H3l386TDbz3Klk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Konstantin Belousov wrote in : |On Mon, Sep 06, 2021 at 04:01:37PM +0200, Steffen Nurpmeso wrote: |> Eric McCorkle wrote in |> : |>|Interesting, I wasn't aware of the upstream module. I'd say that's |>=20 |> It's existence was the reason i have readded (now optional, and |> a tad different) session support for my pam_xdg PAM module, |> because i was thinking that, if such a many-eyes-seen thing of |> a software project that claims to be and aims at being enterprise, |> ships such a terrible and terribly broken thing, then i can also |> offer session tracking. But my manual at least states |>=20 |> CAVEATS |> On Unix systems any =E2=80=9Cdaemonized=E2=80=9D program or scri= pt is reparented \ |> to the |> program running with PID 1, most likely leaving the PAM user \ |> session |> without PAM recognizing this. Yet careless such code may \ ... |If you use reaper facility, that would ensure that all (grand-)children |of your session are always reparented to the reaper and not to init. In |other words, you can reliable know when the session ends. See |procctl(2) PROC_REAP_* commands. | |I believe that reaper-like functionality is available on all current |Unix-like systems, even if under different names. Ah it is really, really cool what becomes possible (everywhere;)! So (Open)PAM should maybe (configurably) enable this does for all programs which actually use modules which use session management. #?0|kent:free-src.git$ git grep PROC_REAP_ origin/main | grep -vE '\.2:|:tests/' | sed -E 's/^(.+:.+):.+$/\1/' | sort -u origin/main:sys/compat/freebsd32/freebsd32_misc.c origin/main:sys/kern/kern_procctl.c origin/main:sys/sys/procctl.h origin/main:usr.bin/timeout/timeout.c I do not have systemd here, but on Linux situation seems similar: #?0|kent:x$ tar -xf /x/balls/shadow/shadow-4.8.1.tar.xz #?0|kent:x$ grep -r REAP shadow-4.8.1/ #?1|kent:x$ tar -xf /x/balls/linux-pam/Linux-PAM-1.5.1.tar.xz #?0|kent:x$ grep -r REAP Linux-PAM-1.5.1/ [yes, pam_unix defines UNIX_REAP, not PR_SET_CHILD_SUBREAPER] #?0|kent:x$ tar -xf /x/balls/openssh/openssh-8.7p1.tar.gz #?0|kent:x$ grep -r REAP openssh-8.7p1/ #?1|kent:x$ Maybe this is why systemd flies, i would guess it does, and this gives you then reliable session management. I did not really know that actually, .. consciously. This is really cool, but still also that upstream OpenZFS module, and my one, and who knows which other PAM module also, perform really bad sad and bitter session counting via counter files, ... but that is a different topic. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed Sep 8 17:52:48 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C02B517A67CB for ; Wed, 8 Sep 2021 17:53:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H4V9W3VWzz4qpp for ; Wed, 8 Sep 2021 17:53:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f170.google.com with SMTP id z2so3379274iln.0 for ; Wed, 08 Sep 2021 10:53:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gvJI9bArDdtBp+I68gvolyUhP7sfeQXhgNdMBwo/2WM=; b=A4EzzFh4nFM43qRBNuzg+rZ4DJ/zF+hJATYAxRAGuLVg6SEHZlvVKIp3k/ogFapC0M qtniqctncU7yxYGSB8IuJMz30Qu7uqU1DZiKRrsdiiZqH8olHyOuzRPE4uPO7IGWq1sT LtgB7wU49mdLNmLf6Pft/GlX+Q7AciSS2PBECwVVVWUMGpIkztCjPu5DL7vlppK2+Z1Q v55WqN3yhkMn7uKIJKGuYpzc/eQjpnx6NVSNrWDBka8TuTVyQ3wMTXVb+SKcUTWmeSE2 Y2IWh3KGyLaYpuz/ODuT/ZRPyOKaVYGP1CM9/sKPR12Mn2NKNrZRL0283TYGYH2rfOE7 6/dQ== X-Gm-Message-State: AOAM530sSmcwCEv0VoXOIXHd0KLxRKqPnBTbeYQi9uAkxfgRANIoBIFv zjM/7yyCP+jFyqIgt4MbUCqbFFmygug9C6u9Jm0Ti8S6poM= X-Google-Smtp-Source: ABdhPJzsdOdqDdjLnpa/cKmonV14dRIJkXSr046X8CTAXlaHvUwjH0nFv7i514JlmqNU7wHX2AR21h3OVH6WDx1QkJU= X-Received: by 2002:a92:7302:: with SMTP id o2mr838083ilc.44.1631123591957; Wed, 08 Sep 2021 10:53:11 -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: Ed Maste Date: Wed, 8 Sep 2021 13:52:48 -0400 Message-ID: Subject: Re: OpenSSH 8.7p1 update for the base system To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4H4V9W3VWzz4qpp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.170 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.170:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.170:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 4 Sept 2021 at 11:59, Ed Maste wrote: > > I'm preparing to update OpenSSH in the FreeBSD base system to 8.7p1, > and am sharing an initial patch for testing. This is now in the tree (commit 19261079b743) - thanks to all who reviewed / tested (on and off list). One thing I forgot to include in the commit message - OpenSSH upstream removed the DSA host key path from the default list some time ago. We kept it slightly longer, but with this update it has been removed. There are still a few local changes and bugfixes that need to be sent upstream, and I hope to do so before OpenSSH 8.8 is released. Also OpenSSH now has support for FIDO/U2F but not yet available in the base system. Finally, this note from upstream's release notes is important: (https://www.openssh.com/releasenotes.html) Imminent deprecation notice =========================== OpenSSH will disable the ssh-rsa signature scheme by default in the next release. In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1 hash algorithm in conjunction with the RSA public key algorithm. It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. Note that the deactivation of "ssh-rsa" signatures does not necessarily require cessation of use for RSA keys. In the SSH protocol, keys may be capable of signing using multiple algorithms. In particular, "ssh-rsa" keys are capable of signing using "rsa-sha2-256" (RSA/SHA256), "rsa-sha2-512" (RSA/SHA512) and "ssh-rsa" (RSA/SHA1). Only the last of these is being turned off by default. This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs that is still enabled by default. The better alternatives include: * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them. * The RFC8709 ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5. * The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7. To check whether a server is using the weak ssh-rsa public key algorithm, for host authentication, try to connect to it after removing the ssh-rsa algorithm from ssh(1)'s allowed list: ssh -oHostKeyAlgorithms=-ssh-rsa user@host If the host key verification fails and no other supported host key types are available, the server software on that host should be upgraded. OpenSSH recently enabled the UpdateHostKeys option by default to assist the client by automatically migrating to better algorithms. [1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) https://eprint.iacr.org/2020/014.pdf From nobody Fri Sep 10 18:51:38 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B9D9317B5A14; Fri, 10 Sep 2021 18:51:41 +0000 (UTC) (envelope-from avg@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 4H5lMx4rLCz4r5J; Fri, 10 Sep 2021 18:51:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 349544E8A; Fri, 10 Sep 2021 18:51:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) To: "net@FreeBSD.org" , hackers@FreeBSD.org From: Andriy Gapon Subject: recvmsg() "short receive" after FIONREAD Message-ID: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> Date: Fri, 10 Sep 2021 21:51:38 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N I observe a problem with the code that can be seen here: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/modules/rtp/sap.c#L142 The code uses ioctl(FIONREAD) to check the size of available data in a socket. Does / should this work? Then the code calls recvmsg() on the socket with single vector with iov_len equal to the size obtained earlier. But the return value from recvmsg() is smaller than the iov_len value. In my test I see 215 vs expected 263 (so, the difference is 48). Does this ring a bell to anyone? I see this on a month old 14.0-CURRENT arm64. -- Andriy Gapon From nobody Fri Sep 10 19:15:37 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EC6B117A26F3; Fri, 10 Sep 2021 19:15:39 +0000 (UTC) (envelope-from avg@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 4H5lvb6TXdz3GDt; Fri, 10 Sep 2021 19:15:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 577D74E91; Fri, 10 Sep 2021 19:15:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) From: Andriy Gapon To: "net@FreeBSD.org" , hackers@FreeBSD.org References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> Subject: Re: recvmsg() "short receive" after FIONREAD Message-ID: <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> Date: Fri, 10 Sep 2021 22:15:37 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 10/09/2021 21:51, Andriy Gapon wrote: > > > I observe a problem with the code that can be seen here: > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/modules/rtp/sap.c#L142 > > > The code uses ioctl(FIONREAD) to check the size of available data in a socket. > Does / should this work? > > Then the code calls recvmsg() on the socket with single vector with iov_len > equal to the size obtained earlier. > > But the return value from recvmsg() is smaller than the iov_len value. > In my test I see 215 vs expected 263 (so, the difference is 48). > > Does this ring a bell to anyone? > I see this on a month old 14.0-CURRENT arm64. > From a quick look at soreceive_dgram() and some dtrace-ing, it seems that each time recvmsg() is called soreceive_dgram() gets an mbuf chain where the first mbuf is MT_SONAME (8), the second one is MT_CONTROL (14) and only the third one is MT_DATA. Could it be that data in the first two mbuf-s (especially the MT_CONTROL one) is reported by FIONREAD? Or, in other words, accounted in sb_acc? But then it's not actually returned, of course, in recvmsg() ? -- Andriy Gapon From nobody Fri Sep 10 19:20:42 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 81E3617A41AE; Fri, 10 Sep 2021 19:20:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H5m1V2cz5z3HgS; Fri, 10 Sep 2021 19:20:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf34.google.com with SMTP id z12so1971716qvx.5; Fri, 10 Sep 2021 12:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kkAhsRL4lhviXZIdCNoN365Ee+BbmlPi3nCQuMQ6kJU=; b=k3Y/UehdDeyehjjOTsIIOP/8jSGvqxse5rVfAB92/k0ne3PFOHpLD89fAldVmTj6XK Y/YrSFr0+hMLVixGVbtnU2ad6MVwieFsscR1mH8aQ715KprTPMRvSmCAWUNuLQjfaArk bSozn78qswTyJ8YXK7ZL/+Ib44PwHNpPR1Hns97bXA2qUVQm4P/q7KxO665mAhdJniKJ hiYadRWkaepSADys/lNqjpV6cI9tkGGXIpON5pc2dyzIUvKfrakkYcHfp5mEZ1Sg+sOh jqqcfaDdWQRjJNSPmI/VnI6mRYk9QMEbWp1aoAKu37gJgen+qSdVrDOlHNuMJNE21iBr MvTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=kkAhsRL4lhviXZIdCNoN365Ee+BbmlPi3nCQuMQ6kJU=; b=JwrcqS1rqatjQOCyxFPx5PB9FkV8pFN6G/i6CdIe4KuaauRp8vchnJoW04U7fPwpNW WSA/37U4NuA+JPOs+5ULrm7qJxXLA67Sk/qB4nHv7lzdzOor4i6mnHzdLprW738xNq1X 4t6tWrkiDlHXZSLQhK/MOCAuqi/TjaI2W7lYO29xow1Tf6J8DsR/VzjkkIt1zSTRksHI rZ2MaGdwd+eIperFOLvXf5aKLA1ZfD8GAhtsJTsnYu5bDSwDTsftT48W6iEIsr1TCIBz YEldEwMsLFFh2S7TEZNqMZP++i2UiKInQimXn806HF/jw02PwEMeuC6eC1SUblo0TyDY Q/jQ== X-Gm-Message-State: AOAM532yC5jsAuxglMiEUQuP7h8uXNsZeq33Q9GWmJawsO4+8R+wfY8I BTew4kiIRIU+6ID+oAEsRDUVvjjj4Z6kVA== X-Google-Smtp-Source: ABdhPJxjwSWZJZjeuXxFkzcYOHKRkEA01QzZojH+eszkCz38igBLnrp4npVNZJ7NVNbOL5CDVDtCpg== X-Received: by 2002:a0c:9a8a:: with SMTP id y10mr10077529qvd.15.1631301640171; Fri, 10 Sep 2021 12:20:40 -0700 (PDT) Received: from nuc ([142.126.175.196]) by smtp.gmail.com with ESMTPSA id g7sm3693998qtj.28.2021.09.10.12.20.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Sep 2021 12:20:39 -0700 (PDT) Date: Fri, 10 Sep 2021 15:20:42 -0400 From: Mark Johnston To: Andriy Gapon Cc: "net@FreeBSD.org" , hackers@freebsd.org Subject: Re: recvmsg() "short receive" after FIONREAD Message-ID: References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> X-Rspamd-Queue-Id: 4H5m1V2cz5z3HgS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Sep 10, 2021 at 09:51:38PM +0300, Andriy Gapon wrote: > > > I observe a problem with the code that can be seen here: > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/modules/rtp/sap.c#L142 > > The code uses ioctl(FIONREAD) to check the size of available data in a socket. > Does / should this work? Yes, FIONREAD returns the number of available bytes in the socket receive buffer. > Then the code calls recvmsg() on the socket with single vector with iov_len > equal to the size obtained earlier. > > But the return value from recvmsg() is smaller than the iov_len value. > In my test I see 215 vs expected 263 (so, the difference is 48). What type of socket is it? Is it possible that there are control messages in the receive buffer? They would be dropped here since the code does not specify a buffer for them, but they are counted in the return value of FIONREAD. > Does this ring a bell to anyone? > I see this on a month old 14.0-CURRENT arm64. It doesn't sound familiar to me at least. From nobody Fri Sep 10 19:35:58 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 835B417AADCE; Fri, 10 Sep 2021 19:36:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H5mM830JMz3NSc; Fri, 10 Sep 2021 19:36:04 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x832.google.com with SMTP id l24so2489804qtj.4; Fri, 10 Sep 2021 12:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=yYrU/LO1iaox+aPVZZK2z6w0Yn8htO0Z5//kZSC4Fys=; b=jPArV8/S4y5hhaSuEqLZJmjPAO4IK3ZkOqEZ1L38d1v5fgtj8b4mJUcLa5UwOBe02D v8LwvPVA0fxKEXIYIPTTrKEve5shb/KzDRjUCqpVSAXMAeDMRjOWLnmgyx1+48S3Q7Xj t+ZKfk/uS3B1qLepy5OTdB9ySxi8fBP35OpCDzKgvzZdaKZxz3mSJujwZHuD6Q6fzhAI 9LlRm0N+g1mi64eRrPHJA6dWeDxLf8qIQelvNKABAcmpj2cQrvPMi/L6rWuQYQPdJsFB le+QDrT/nEkiMziPEuXtILZGaWUnFrDENOmEjnvdUhM1TrM21nxUNPXj2VWnBnrhNXxr 5/5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=yYrU/LO1iaox+aPVZZK2z6w0Yn8htO0Z5//kZSC4Fys=; b=XRUR7UwdKEbr/QxSSVLXg1D1fGR9mzR//go8B0ZT8m7M8GMQw2uD2oeZredNy8SiT+ M7p0SEWnBurk34mbdYseMK3vd/IqEs9h9NYroGZcVpggezMrlVYkAk0W/kjazo9Ky13p 6usQU6tlZUv071sIs+Rr0USufU92UR1nF5J0SGQWOSy7N4rIlVklF77yXaM9fRCVBnwM Y/frKkC8T7OrqU5BAejfoTlA9d/s9p6tG6Hjq7EKuVsktfeQdjaWuxm/CqQMk9YIiuiS WzDpv4KzH+8B6uV43oYkfJaV0WauoFEwIi+jKEae+1Lh8/fn393h2QgA/pdphZB0XRpV Tkxw== X-Gm-Message-State: AOAM530tYJ13GOItXlGyKiMyzkXNG+9pTFadDnRPkN8YQmqMobYBiYRk Jhom1Lu6+gpS7r46RDD60Cr78jhEF/PG8g== X-Google-Smtp-Source: ABdhPJxUwZ+NUIRXydySr9nKFfEOn2hQFwxAWnYmZSxfg71pEKVQxwhIc/G+4UaKh57/L2YNtMNJIQ== X-Received: by 2002:a05:622a:118f:: with SMTP id m15mr9846629qtk.107.1631302557999; Fri, 10 Sep 2021 12:35:57 -0700 (PDT) Received: from nuc ([142.126.175.196]) by smtp.gmail.com with ESMTPSA id d14sm1010898qto.36.2021.09.10.12.35.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Sep 2021 12:35:57 -0700 (PDT) Date: Fri, 10 Sep 2021 15:35:58 -0400 From: Mark Johnston To: Andriy Gapon Cc: "net@FreeBSD.org" , hackers@freebsd.org Subject: Re: recvmsg() "short receive" after FIONREAD Message-ID: References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> X-Rspamd-Queue-Id: 4H5mM830JMz3NSc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Sep 10, 2021 at 10:15:37PM +0300, Andriy Gapon wrote: > On 10/09/2021 21:51, Andriy Gapon wrote: > > > > > > I observe a problem with the code that can be seen here: > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/modules/rtp/sap.c#L142 > > > > > > The code uses ioctl(FIONREAD) to check the size of available data in a socket. > > Does / should this work? > > > > Then the code calls recvmsg() on the socket with single vector with iov_len > > equal to the size obtained earlier. > > > > But the return value from recvmsg() is smaller than the iov_len value. > > In my test I see 215 vs expected 263 (so, the difference is 48). > > > > Does this ring a bell to anyone? > > I see this on a month old 14.0-CURRENT arm64. > > > > From a quick look at soreceive_dgram() and some dtrace-ing, it seems that each > time recvmsg() is called soreceive_dgram() gets an mbuf chain where the first > mbuf is MT_SONAME (8), the second one is MT_CONTROL (14) and only the third one > is MT_DATA. > > Could it be that data in the first two mbuf-s (especially the MT_CONTROL one) is > reported by FIONREAD? Or, in other words, accounted in sb_acc? > But then it's not actually returned, of course, in recvmsg() ? Indeed, I suspect that this is the problem. Note that for kevent(EVFILT_READ) we subtract the number of control message bytes from the returned value, see filt_soread(). I wonder if FIONREAD should do the same thing. From nobody Fri Sep 10 19:38:21 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7F3C317ADEF0; Fri, 10 Sep 2021 19:38:24 +0000 (UTC) (envelope-from avg@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 4H5mPr1crkz3Qjy; Fri, 10 Sep 2021 19:38:24 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7D8084AB4; Fri, 10 Sep 2021 19:38:23 +0000 (UTC) (envelope-from avg@freebsd.org) From: Andriy Gapon Subject: Re: recvmsg() "short receive" after FIONREAD To: Mark Johnston Cc: "net@FreeBSD.org" , hackers@freebsd.org References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> Message-ID: Date: Fri, 10 Sep 2021 22:38:21 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 10/09/2021 22:35, Mark Johnston wrote: > On Fri, Sep 10, 2021 at 10:15:37PM +0300, Andriy Gapon wrote: >> On 10/09/2021 21:51, Andriy Gapon wrote: >>> >>> >>> I observe a problem with the code that can be seen here: >>> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/modules/rtp/sap.c#L142 >>> >>> >>> The code uses ioctl(FIONREAD) to check the size of available data in a socket. >>> Does / should this work? >>> >>> Then the code calls recvmsg() on the socket with single vector with iov_len >>> equal to the size obtained earlier. >>> >>> But the return value from recvmsg() is smaller than the iov_len value. >>> In my test I see 215 vs expected 263 (so, the difference is 48). >>> >>> Does this ring a bell to anyone? >>> I see this on a month old 14.0-CURRENT arm64. >>> >> >> From a quick look at soreceive_dgram() and some dtrace-ing, it seems that each >> time recvmsg() is called soreceive_dgram() gets an mbuf chain where the first >> mbuf is MT_SONAME (8), the second one is MT_CONTROL (14) and only the third one >> is MT_DATA. >> >> Could it be that data in the first two mbuf-s (especially the MT_CONTROL one) is >> reported by FIONREAD? Or, in other words, accounted in sb_acc? >> But then it's not actually returned, of course, in recvmsg() ? > > Indeed, I suspect that this is the problem. Note that for > kevent(EVFILT_READ) we subtract the number of control message bytes from > the returned value, see filt_soread(). I wonder if FIONREAD should do > the same thing. Thank you for the suggestion. I think that it is a reasonable expectation that FIONREAD returns a number of bytes that can be actually read. I'll look at filt_soread(). Thank you! -- Andriy Gapon From nobody Fri Sep 10 19:40:23 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 014EA17B0038; Fri, 10 Sep 2021 19:40:25 +0000 (UTC) (envelope-from avg@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 4H5mS86fbFz3hyr; Fri, 10 Sep 2021 19:40:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 54C9B535B; Fri, 10 Sep 2021 19:40:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Subject: Re: recvmsg() "short receive" after FIONREAD From: Andriy Gapon To: Mark Johnston Cc: "net@FreeBSD.org" , hackers@freebsd.org References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> Message-ID: <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> Date: Fri, 10 Sep 2021 22:40:23 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 10/09/2021 22:38, Andriy Gapon wrote: > On 10/09/2021 22:35, Mark Johnston wrote: >> Indeed, I suspect that this is the problem.  Note that for >> kevent(EVFILT_READ) we subtract the number of control message bytes from >> the returned value, see filt_soread().  I wonder if FIONREAD should do >> the same thing. > > Thank you for the suggestion. > I think that it is a reasonable expectation that FIONREAD returns a number of > bytes that can be actually read. > I'll look at filt_soread(). kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; Is this it? Looks simple enough for a quick test :) -- Andriy Gapon From nobody Sat Sep 11 08:15:12 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3B12B17C7E38; Sat, 11 Sep 2021 08:15:16 +0000 (UTC) (envelope-from avg@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 4H65C817FMz3skF; Sat, 11 Sep 2021 08:15:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 88B2AB5AA; Sat, 11 Sep 2021 08:15:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Subject: Re: recvmsg() "short receive" after FIONREAD From: Andriy Gapon To: Mark Johnston Cc: "net@FreeBSD.org" , hackers@freebsd.org References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> Message-ID: Date: Sat, 11 Sep 2021 11:15:12 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 10/09/2021 22:40, Andriy Gapon wrote: > On 10/09/2021 22:38, Andriy Gapon wrote: >> On 10/09/2021 22:35, Mark Johnston wrote: >>> Indeed, I suspect that this is the problem.  Note that for >>> kevent(EVFILT_READ) we subtract the number of control message bytes from >>> the returned value, see filt_soread().  I wonder if FIONREAD should do >>> the same thing. >> >> Thank you for the suggestion. >> I think that it is a reasonable expectation that FIONREAD returns a number of >> bytes that can be actually read. >> I'll look at filt_soread(). > > kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; > Is this it? > Looks simple enough for a quick test :) Works perfectly. Should I just commit it or is a larger discussion needed? -- Andriy Gapon From nobody Sat Sep 11 14:13:37 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 393A017CD988; Sat, 11 Sep 2021 14:13:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6F8f0bFZz3FN2; Sat, 11 Sep 2021 14:13:38 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82a.google.com with SMTP id s32so4203094qtc.12; Sat, 11 Sep 2021 07:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Nl1Q3GpWIJBeymU+A6/6qPzFh1Fctu86VBLkGOoQhco=; b=asVtX2SzGprbis1RJw/HjcJlpaTWprCBwdGkrUx/wpFrjVRCnHY0aqD0PK0F6U+ZOx Blt/EzvDayFu4HmHuwHn4BuaiZELSaYy+cdyZ9aJ29RvdANmEJ51/+FBpEjzBrTjxKLQ mSSws8BNn4K+c7F78VaDlQb62pXXpZ4WfeEMBdK4HJgAt0NcWAIS1oMdNVNhLcCE02zL +2euyAU3kOsM0gTjPEFqbI33wBogcFB2lJFlmpF7mptmxtbugENLka8lindTveZPKKPf bfk7+A2vtfOM9GO3fbroZsvHkLddYLytKOo/Uuhag/uHtzZlLkdyoNrlmYv5IigLMavw vznw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=Nl1Q3GpWIJBeymU+A6/6qPzFh1Fctu86VBLkGOoQhco=; b=2tBzFnvCuVowkk84WJyUlKaBSb7XhKyDS5LrdvpgeRVyrzAGjKb7Oa4L6DxcGau6iU 228aB+Z/peGyFDAQ+0A5dTyR6Wb2ZfALAg6Jc0dZCcliel/y0H6YrDFBe5ATcoHN8ox9 s0/DEbtmgAY35ZjPlZpxTvIKkrzKgW6Cb1w+blfSe9PUgurKLwnOXMD7Ex1soGA3NgO/ QrEIaEtCzCR/Vp6iF91wlnB3ESSna4Np9G6HmZt4P5yWRDJwaq6xKflYVq//MLI2g/53 ExpGWfCt2QXca3ttIMDWcUuvQ5fjzKCPxGejPuLDjlbn/fICDravrhSic1sy1jKEI9Ss XO9Q== X-Gm-Message-State: AOAM533X2aALZkk7AfM1CpT0jHzkzxjuOQKPYid3oLCFU7266LhEKpun vLCa2ruv9+Mv/eyWHT/uN2yAtoGUNRnL1g== X-Google-Smtp-Source: ABdhPJytBohmWdr/eNe4KJV1E0xE7aldHbBnJofOw5e1NHWNFT3wihGv4Ulht0b2QYZ+Wqg8ctkhwA== X-Received: by 2002:aed:3004:: with SMTP id 4mr2348689qte.407.1631369617377; Sat, 11 Sep 2021 07:13:37 -0700 (PDT) Received: from nuc ([142.126.175.196]) by smtp.gmail.com with ESMTPSA id t26sm1235668qkm.0.2021.09.11.07.13.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Sep 2021 07:13:37 -0700 (PDT) Date: Sat, 11 Sep 2021 10:13:37 -0400 From: Mark Johnston To: Andriy Gapon Cc: "net@FreeBSD.org" , hackers@freebsd.org Subject: Re: recvmsg() "short receive" after FIONREAD Message-ID: References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4H6F8f0bFZz3FN2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Sep 11, 2021 at 11:15:12AM +0300, Andriy Gapon wrote: > On 10/09/2021 22:40, Andriy Gapon wrote: > > On 10/09/2021 22:38, Andriy Gapon wrote: > >> On 10/09/2021 22:35, Mark Johnston wrote: > >>> Indeed, I suspect that this is the problem. Note that for > >>> kevent(EVFILT_READ) we subtract the number of control message bytes from > >>> the returned value, see filt_soread(). I wonder if FIONREAD should do > >>> the same thing. > >> > >> Thank you for the suggestion. > >> I think that it is a reasonable expectation that FIONREAD returns a number of > >> bytes that can be actually read. > >> I'll look at filt_soread(). > > > > kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; > > Is this it? > > Looks simple enough for a quick test :) > > > Works perfectly. > Should I just commit it or is a larger discussion needed? I think the semantic change is ok. Did you change FIONREAD to lock the sockbuf? I think it would be necessary to avoid races with pulseaudio: sb_acc is modified before sb_ctl, so there could be windows where sbavail(sb) - sb->sb_ctl gives a larger. And, it is not really safe to lock the sockbuf itself, since it may be overwritten by a listen(2) call. SOCK_RECVBUF_LOCK(so) should be used instead. From nobody Sat Sep 11 14:16:23 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B1E1017A02CF; Sat, 11 Sep 2021 14:16:27 +0000 (UTC) (envelope-from avg@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 4H6FCv3Vbhz3HSX; Sat, 11 Sep 2021 14:16:27 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D959EE40B; Sat, 11 Sep 2021 14:16:26 +0000 (UTC) (envelope-from avg@freebsd.org) From: Andriy Gapon Subject: Re: recvmsg() "short receive" after FIONREAD To: Mark Johnston Cc: "net@FreeBSD.org" , hackers@freebsd.org References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> Message-ID: Date: Sat, 11 Sep 2021 17:16:23 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 11/09/2021 17:13, Mark Johnston wrote: > I think the semantic change is ok. Did you change FIONREAD to lock the > sockbuf? I think it would be necessary to avoid races with pulseaudio: > sb_acc is modified before sb_ctl, so there could be windows where > sbavail(sb) - sb->sb_ctl gives a larger. > > And, it is not really safe to lock the sockbuf itself, since it may be > overwritten by a listen(2) call. SOCK_RECVBUF_LOCK(so) should be used > instead. I didn't think about the locking, so I didn't add it. My current patch is trivial: @@ -210,7 +210,7 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, struct ucred *active_cred, if (SOLISTENING(so)) { error = EINVAL; } else { - *(int *)data = sbavail(&so->so_rcv); + *(int *)data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; } break; Let me try adding the lock. Thank you again! -- Andriy Gapon From nobody Sat Sep 11 14:28:11 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 44AEF17A4E7A; Sat, 11 Sep 2021 14:28:13 +0000 (UTC) (envelope-from avg@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 4H6FTT1Kqmz3Ltj; Sat, 11 Sep 2021 14:28:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 91010E717; Sat, 11 Sep 2021 14:28:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) From: Andriy Gapon To: Mark Johnston Cc: "net@FreeBSD.org" , hackers@freebsd.org References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> Subject: Re: recvmsg() "short receive" after FIONREAD Message-ID: <4499e2b0-d1e7-5bee-519c-783fb930fc06@FreeBSD.org> Date: Sat, 11 Sep 2021 17:28:11 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 11/09/2021 17:16, Andriy Gapon wrote: > On 11/09/2021 17:13, Mark Johnston wrote: >> I think the semantic change is ok.  Did you change FIONREAD to lock the >> sockbuf?  I think it would be necessary to avoid races with pulseaudio: >> sb_acc is modified before sb_ctl, so there could be windows where >> sbavail(sb) - sb->sb_ctl gives a larger. >> >> And, it is not really safe to lock the sockbuf itself, since it may be >> overwritten by a listen(2) call.  SOCK_RECVBUF_LOCK(so) should be used >> instead. > > I didn't think about the locking, so I didn't add it. > My current patch is trivial: > @@ -210,7 +210,7 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, struct > ucred *active_cred, >                 if (SOLISTENING(so)) { >                         error = EINVAL; >                 } else { > -                       *(int *)data = sbavail(&so->so_rcv); > +                       *(int *)data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; >                 } >                 break; > > Let me try adding the lock. By the way, soo_stat() seems to be another good example to follow. -- Andriy Gapon From nobody Sat Sep 11 18:25:42 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 515C617C6DA1; Sat, 11 Sep 2021 18:25:46 +0000 (UTC) (envelope-from avg@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 4H6LlZ1nvbz3ljP; Sat, 11 Sep 2021 18:25:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A1FE9FF28; Sat, 11 Sep 2021 18:25:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Subject: Re: recvmsg() "short receive" after FIONREAD From: Andriy Gapon To: Mark Johnston Cc: "net@FreeBSD.org" , hackers@freebsd.org References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> <4499e2b0-d1e7-5bee-519c-783fb930fc06@FreeBSD.org> Message-ID: <82143b59-a0e6-c23e-8b47-29d8d41eb5b4@FreeBSD.org> Date: Sat, 11 Sep 2021 21:25:42 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <4499e2b0-d1e7-5bee-519c-783fb930fc06@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 11/09/2021 17:28, Andriy Gapon wrote: > On 11/09/2021 17:16, Andriy Gapon wrote: >> On 11/09/2021 17:13, Mark Johnston wrote: >>> I think the semantic change is ok.  Did you change FIONREAD to lock the >>> sockbuf?  I think it would be necessary to avoid races with pulseaudio: >>> sb_acc is modified before sb_ctl, so there could be windows where >>> sbavail(sb) - sb->sb_ctl gives a larger. >>> >>> And, it is not really safe to lock the sockbuf itself, since it may be >>> overwritten by a listen(2) call.  SOCK_RECVBUF_LOCK(so) should be used >>> instead. >> >> I didn't think about the locking, so I didn't add it. >> My current patch is trivial: >> @@ -210,7 +210,7 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, struct >> ucred *active_cred, >>                  if (SOLISTENING(so)) { >>                          error = EINVAL; >>                  } else { >> -                       *(int *)data = sbavail(&so->so_rcv); >> +                       *(int *)data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; >>                  } >>                  break; >> >> Let me try adding the lock. > > By the way, soo_stat() seems to be another good example to follow. So, this is what I've got: diff --git a/sys/kern/sys_socket.c b/sys/kern/sys_socket.c index e53b0367960b..11ee03703407 100644 --- a/sys/kern/sys_socket.c +++ b/sys/kern/sys_socket.c @@ -210,7 +210,12 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, struct ucred *active_cred, if (SOLISTENING(so)) { error = EINVAL; } else { - *(int *)data = sbavail(&so->so_rcv); + struct sockbuf *sb; + + sb = &so->so_rcv; + SOCKBUF_LOCK(sb); + *(int *)data = sbavail(sb) - sb->sb_ctl; + SOCKBUF_UNLOCK(sb); } break; -- Andriy Gapon From nobody Sat Sep 11 18:40:56 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7771B17AF178; Sat, 11 Sep 2021 18:41:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6M5C2hPSz3sNN; Sat, 11 Sep 2021 18:41:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x733.google.com with SMTP id w78so5919726qkb.4; Sat, 11 Sep 2021 11:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=ypG1zs4vUIYr4Y3Alkyz8mJOsTvt+RddZ1CgA7C05TQ=; b=Be+5tOpwyq5vYm+tNehEcypQTJME2Uatp/z/u1FdIO0/Bs/zGeLu7pIn87+obtXMoH fT2IxrfbEkSeca5K0FoubbQxNHSDyqhK4apQZqZgbD81zVVxxLiyBAiqzwAR2uPwvueo V5YA2P1LqD1q/m4ARhVMeNvar1kSWjwVj8UFp0XM77aZeKUs0pUgsim9j9Gp3VVydvLn +flKbfH5ltbwsHb8fNayCR6/Yo9Ii5MDictnqFWqVGRSitIRn9y1wfJoCHklXJ9SudlA tUY0G5pJgHtAgLP4iNdNlDv/sXDISHOSZsYwF6BQUzHa974kFdj1xJZV0R8cMrR8Px2d sWvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=ypG1zs4vUIYr4Y3Alkyz8mJOsTvt+RddZ1CgA7C05TQ=; b=ADJsBEM8AR7cEqQzDqVe/BZ+xErx1XDYMCoAF2pE4DoL3R+ZVnc/QbfPigPIgKWzLE 0IQt3WuNJVVfK73qRyMitVoeIkSgTDIJmy8Mf91G18vNTp5/1id7ykquXNAADtS1pl+I whS2MUsH7Pe3jZAiwn8D6zpWkfwjibXyjL1+uH7+oLzIwc+E2FdZQF2i7lACbnmUN5/l d/KIGHrFLzRIehyXBQGiK8FIqeyTtdroE+bclZWeI08+KdlLwpStGslUeyYSqg9oUhpa vz0jttCpn6CnoZVuTcjeY0hnu64p1mazD1ebyrv2TJbks2uxfOO+Udg+BJNk42VWz+PJ ZvLA== X-Gm-Message-State: AOAM532UhNvXIEzNc+kSQhd+vQ/69IwVEa0/H4O0TcX1flmSpQDzNegj k4Ep2Fe6Jg3w51HzPE328IFTs6fqOYmJAA== X-Google-Smtp-Source: ABdhPJwEvtvSvuICamwThXzXrjzlpNd9itjytQoyq53ZvT635/UiF8TWiWA0oCsdcaRJfW9CjkjG1w== X-Received: by 2002:a37:9481:: with SMTP id w123mr3106737qkd.75.1631385655674; Sat, 11 Sep 2021 11:40:55 -0700 (PDT) Received: from nuc ([142.126.175.196]) by smtp.gmail.com with ESMTPSA id v10sm1667799qkj.79.2021.09.11.11.40.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Sep 2021 11:40:55 -0700 (PDT) Date: Sat, 11 Sep 2021 14:40:56 -0400 From: Mark Johnston To: Andriy Gapon Cc: "net@FreeBSD.org" , hackers@freebsd.org Subject: Re: recvmsg() "short receive" after FIONREAD Message-ID: References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> <4499e2b0-d1e7-5bee-519c-783fb930fc06@FreeBSD.org> <82143b59-a0e6-c23e-8b47-29d8d41eb5b4@FreeBSD.org> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <82143b59-a0e6-c23e-8b47-29d8d41eb5b4@FreeBSD.org> X-Rspamd-Queue-Id: 4H6M5C2hPSz3sNN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Sep 11, 2021 at 09:25:42PM +0300, Andriy Gapon wrote: > On 11/09/2021 17:28, Andriy Gapon wrote: > > On 11/09/2021 17:16, Andriy Gapon wrote: > >> On 11/09/2021 17:13, Mark Johnston wrote: > >>> I think the semantic change is ok. Did you change FIONREAD to lock the > >>> sockbuf? I think it would be necessary to avoid races with pulseaudio: > >>> sb_acc is modified before sb_ctl, so there could be windows where > >>> sbavail(sb) - sb->sb_ctl gives a larger. > >>> > >>> And, it is not really safe to lock the sockbuf itself, since it may be > >>> overwritten by a listen(2) call. SOCK_RECVBUF_LOCK(so) should be used > >>> instead. > >> > >> I didn't think about the locking, so I didn't add it. > >> My current patch is trivial: > >> @@ -210,7 +210,7 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, struct > >> ucred *active_cred, > >> if (SOLISTENING(so)) { > >> error = EINVAL; > >> } else { > >> - *(int *)data = sbavail(&so->so_rcv); > >> + *(int *)data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; > >> } > >> break; > >> > >> Let me try adding the lock. > > > > By the way, soo_stat() seems to be another good example to follow. > > So, this is what I've got: > diff --git a/sys/kern/sys_socket.c b/sys/kern/sys_socket.c > index e53b0367960b..11ee03703407 100644 > --- a/sys/kern/sys_socket.c > +++ b/sys/kern/sys_socket.c > @@ -210,7 +210,12 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, struct > ucred *active_cred, > if (SOLISTENING(so)) { > error = EINVAL; > } else { > - *(int *)data = sbavail(&so->so_rcv); > + struct sockbuf *sb; > + > + sb = &so->so_rcv; > + SOCKBUF_LOCK(sb); > + *(int *)data = sbavail(sb) - sb->sb_ctl; > + SOCKBUF_UNLOCK(sb); > } > break; It should use SOCK_RECVBUF_LOCK() (see https://cgit.freebsd.org/src/commit/?id=74a68313b503940158a2e8e8f02626d7cdbdaff9 ): sb = &so->so_rcv; SOCK_RECVBUF_LOCK(so); if (SOLISTENING(so)) error = EINVAL; else *(int *)data = sbavail(sb) - sb->sb_ctl; SOCK_RECVBUF_UNLOCK(so); Otherwise a concurrent listen(2) will clobber the pointer used by SOCKBUF_LOCK(). From nobody Sun Sep 12 09:13:52 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7908217A7883; Sun, 12 Sep 2021 09:13:55 +0000 (UTC) (envelope-from avg@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 4H6kSM2f28z3Qyj; Sun, 12 Sep 2021 09:13:55 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C0A7F27AC8; Sun, 12 Sep 2021 09:13:54 +0000 (UTC) (envelope-from avg@freebsd.org) From: Andriy Gapon Subject: Re: recvmsg() "short receive" after FIONREAD To: Mark Johnston Cc: "net@FreeBSD.org" , hackers@freebsd.org References: <500a2272-c1b3-3f97-0096-9fe8117c4b95@FreeBSD.org> <6f455869-cbdd-ee20-f2f8-f633e22071e9@FreeBSD.org> <4a2165c5-b97b-8fb7-9ada-0acae3197824@FreeBSD.org> <4499e2b0-d1e7-5bee-519c-783fb930fc06@FreeBSD.org> <82143b59-a0e6-c23e-8b47-29d8d41eb5b4@FreeBSD.org> Message-ID: Date: Sun, 12 Sep 2021 12:13:52 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 11/09/2021 21:40, Mark Johnston wrote: > On Sat, Sep 11, 2021 at 09:25:42PM +0300, Andriy Gapon wrote: >> So, this is what I've got: >> diff --git a/sys/kern/sys_socket.c b/sys/kern/sys_socket.c >> index e53b0367960b..11ee03703407 100644 >> --- a/sys/kern/sys_socket.c >> +++ b/sys/kern/sys_socket.c >> @@ -210,7 +210,12 @@ soo_ioctl(struct file *fp, u_long cmd, void *data, struct >> ucred *active_cred, >> if (SOLISTENING(so)) { >> error = EINVAL; >> } else { >> - *(int *)data = sbavail(&so->so_rcv); >> + struct sockbuf *sb; >> + >> + sb = &so->so_rcv; >> + SOCKBUF_LOCK(sb); >> + *(int *)data = sbavail(sb) - sb->sb_ctl; >> + SOCKBUF_UNLOCK(sb); >> } >> break; > > It should use SOCK_RECVBUF_LOCK() (see > https://cgit.freebsd.org/src/commit/?id=74a68313b503940158a2e8e8f02626d7cdbdaff9 > ): > > sb = &so->so_rcv; > SOCK_RECVBUF_LOCK(so); > if (SOLISTENING(so)) > error = EINVAL; > else > *(int *)data = sbavail(sb) - sb->sb_ctl; > SOCK_RECVBUF_UNLOCK(so); > > Otherwise a concurrent listen(2) will clobber the pointer used by > SOCKBUF_LOCK(). > Oh, I see now. I haven't pulled that version yet, so I could not find SOCK_RECVBUF_LOCK in my tree :-) Since you have the change and you did all the thinking work anyway, could you please commit it? Thanks! -- Andriy Gapon