From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 515322550A for ; Thu, 25 Apr 2024 14:25:42 +0200 (CEST) Received: (qmail 4095 invoked by uid 550); 25 Apr 2024 12:25:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 4042 invoked from network); 25 Apr 2024 12:25:37 -0000 Date: Thu, 25 Apr 2024 08:25:49 -0400 From: Rich Felker To: lolzery wowzery Cc: musl@lists.openwall.com, Duncan Bellamy , info@bnoordhuis.nl, tony.ambardar@gmail.co Message-ID: <20240425122548.GQ4163@brightrain.aerifal.cx> References: <20200119121247.37310-1-info@bnoordhuis.nl> <20220831190735.52016-1-dunk@denkimushi.com> <20220831190735.52016-2-dunk@denkimushi.com> <20240224165632.GA4163@brightrain.aerifal.cx> <20240424193038.GP4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH 1/2] V3 resubmitting old statx patch with changes On Wed, Apr 24, 2024 at 07:55:32PM -0400, lolzery wowzery wrote: > Hi all! I'm new to git over email, new to musl, and I want to really > get into contributing to musl. So, I'd really appreciate any > tips/comments/info for a newbie like me! > > Please do not merge these changes yet. There's numerous problems with > this code above and beyond the issues you pointed out, statx is already in musl 1.2.5 (commit b817541f1cfd). If there are other problems than the ones I fixed when merging it and the stx_attributes field, please report them here rather than spending time trying to make a comprehensive changeset for a lot of things that might or might not actually be wrong. > and each of > those issues led me down successive rabbit holes all over the musl > source code and I've ended up opening a sizable can of worms, > including io race condition bugs in fallback conditions, Can you clarify what you mean? There are some places where correctly atomic fallback is impossible and the fallback is best-effort only. This is generally only for missing O_CLOEXEC type functionality. If there are others, please report. > symbol > weakness problems, This sounds unlikely. It's more likely that you misunderstand how/why they're used. But I'm happy to look at your findings. > header/struct misorganization, and bugs in syscall > support detection making musl silently/unexpectedly fail under certain > seccomp configurations. It's expected to fail catastrophically if seccomp filters modify syscall behavior in ways that make forward progress impossible (e.g. blocking close or something) or that lie about the cause of failure (the classic but badly wrong practice of using EPERM where ENOSYS was the correct code for syscalls not available in the sandbox). This is inherently not a supportable configuration. Generally musl always uses the oldest-possible syscall that can fully meet the requirements. If it has to try a new syscall first (like statx on 32-bit, since the legacy syscalls don't support full-range time_t and we don't know until after stat whether the times fit in 32 bits), it falls back on ENOSYS. So as long as seccomp filters are using semantically correct error codes, things should generally work. But it's the responsibility of the seccomp filter authors to ensure they're doing this right. > Also, let me cite the earlier patch from tony.ambardar@gmail.com about > renameat2. My patch will include a full proper renameat2 > implementation with validation and fallback and will compile on > systems where SYS_renameat2 is undefined (using exclusively the > fallback.) It's never undefined. That's not how this works. If you're making out-of-tree bare-metal ports and don't want the overhead of having to add new syscalls like this, you can do something like define the SYS_* macros for them such that syscall_arch.h can statically catch that they're nonexistant (e.g. by given them values in some high range) and directly return -ENOSYS; then the code would collapse down as you want with the ENOSYS path being always-taken. Note that there is no way to emulate the nonzero flags for renameat2 without race conditions. Since this is not standard/mandatory functionality, the right thing to do is just return an error for "unsupported flags", not try to emulate them. > I recognize I probably sound like an over-eager-beaver fussing over > fools-gold as I'm new and none of you know me. (That's the assumption > I myself would make if a new guy showed up claiming to have lots of > bug fixes and stuff.) So, please suspend your disbelief for a short > while until I can give my full report and all fixes tomorrow for > everyone to review. Give me a chance to prove my commitment to musl > and watch as I uphold my pledge to maintain my areas of the code in > musl and keep them ship-shape. > > Have a great day everyone and really looking forwards to sharing my > full report tomorrow!, OK, please send. Rich