From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2211 invoked from network); 12 Jan 2024 16:54:21 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 12 Jan 2024 16:54:21 -0000 Received: (qmail 26221 invoked by uid 550); 12 Jan 2024 16:52:39 -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 26189 invoked from network); 12 Jan 2024 16:52:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705078446; x=1705683246; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=36J8GYA+d/lmg5+gKKNyfdJ4XyINjdwoBcaJpgA9tBI=; b=qHrVUCMWO8nV6ies0wm/xdnFT9LFYk2iGyUZN42tuQP3g0UU1GCse/R6cc8JOtmuly cwFBM2EikcHC0Q36DUfDRDVs2S6h+mqNzG3jO7Wv5dDtp9Fa2nC/N5NYLDpMlr/PGRzT xw/LyDa21tmUD7V3J3RgQUGj8zcWBT8mYNKSi1peAL6vF7w/9tuwQ3uxyBTc3UFnFZiT bbDwkkz6+ivUtDr7nJ7xej6g9TYD4jZQcKC/oV6lPmPN8Si4bKkyjcyqUpD4Nv0VnfuT R3UrtgKzV4+kc63rhCU3s1o7f7lkfxNwFs8fmr59osS0cHHsTqK97lqU4Lpt8Dlr1Oyb TQKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705078446; x=1705683246; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=36J8GYA+d/lmg5+gKKNyfdJ4XyINjdwoBcaJpgA9tBI=; b=N9oSXabjjwpAb8hUxwCtR3BzxDV4MawWooD+AxYFabCYOFSXthOWyeyvEeErrQ37TW DT852QJBgTQ+IUvLNWhrxKunH5bzx6UT+2+AvZn+TZYeItVwnDRIZazQeX7MnErlF27z aRLEW2BCSo7xb9ps9PUj+zG8l95y0hbZADsvDWhl1B63aj6ViWY6PdrhkSf4yvbOTz/5 KxsDmEgxUPGarmHIZJmtPfpAgPMUJIVoHw900D/2K5vvRR5fWmVX5tmHpYcoACXCY5PA +Lasnu+R6rXjmgMb/IU/pCe4FcgZUEkx5EOTVbscKEnZf9SRkaeLJlJW1zJh4Eywj1/4 LNcQ== X-Gm-Message-State: AOJu0Ywvlnmm9cS1UebasPH9zrWh249izUe2VWvM0JnMcF+7xgT8tgXN jILl6f8JuxWLjmhbEmZ0jnZqlYh40dAVqxWrQeDdZ+WE95aH X-Google-Smtp-Source: AGHT+IEUkBM5qQ3eF9QOybH7lK2KD5blgcYe5RnLJEynMNTqzzsXdYvPDq7Er54NF0dh5KcULZ+bTHHMLtPmVCwf1pI= X-Received: by 2002:a81:c809:0:b0:5f5:1b6:37b7 with SMTP id n9-20020a81c809000000b005f501b637b7mr1703334ywi.12.1705078445984; Fri, 12 Jan 2024 08:54:05 -0800 (PST) MIME-Version: 1.0 References: <20240109190726.GO4163@brightrain.aerifal.cx> <20240110015837.GQ4163@brightrain.aerifal.cx> In-Reply-To: <20240110015837.GQ4163@brightrain.aerifal.cx> From: enh Date: Fri, 12 Jan 2024 08:53:54 -0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com, jvoisin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Protect pthreads' mutexes against use-after-destroy On Tue, Jan 9, 2024 at 5:58=E2=80=AFPM Rich Felker wrote: > > On Tue, Jan 09, 2024 at 03:27:37PM -0800, enh wrote: > > On Tue, Jan 9, 2024 at 11:07=E2=80=AFAM Rich Felker w= rote: > > > > > > On Tue, Jan 09, 2024 at 03:37:17PM +0100, jvoisin wrote: > > > > Ohai, > > > > > > > > as discussed on irc, Android's bionic has a check to prevent > > > > use-after-destroy on phtread mutexes > > > > (https://github.com/LineageOS/android_bionic/blob/e0aac7df6f58138da= e903b5d456c947a3f8092ea/libc/bionic/pthread_mutex.cpp#L803), > > > > and musl doesn't. > > > > > > > > While odds are that this is a super-duper common bug, it would stil= l be > > > > nice to have this kind of protection, since it's cheap, and would > > > > prevent/make it easy to diagnose weird states. > > > > > > > > Is this something that should/could be implemented? > > > > > > > > o/ > > > > > > I think you meant that the odds are it's not common. > > > > it was common enough (and hard enough to debug) that we added this > > "best effort" error detection to bionic :-) > > Thanks! That's useful information (and disturbing...) yeah ... dan albert (who owns the Android NDK) points out that with a large enough ecosystem, any mistake you can imagine -- and many you can't -- aren't just possible, they're probable :-) > > > There's already > > > enough complexity in the code paths for supporting all the different > > > mutex types that my leaning would be, if we do any hardening for > > > use-after-destroy, that it should probably just take the form of > > > putting the object in a state that will naturally deadlock or error > > > rather than adding extra checks to every path where it's used. > > > > yeah, the _other_ reason we have the abort is that we've struggled > > over the years to make it clear to the _callers_ that -- just because > > you crash/hang in libc -- it's the _caller's_ bug. explicitly saying > > so helps. (though we still get a decent number of people who don't > > read/don't understand.) > > That's a problem we've just not tried to address in musl, but indeed > it does happen fairly often. If we did try at some point, I think it > would be by setting up a state to make the reason more clear in the > debugger, not producing any output. But personally I'd like to keep > driving home the message that the point of crash does not mean > anything about responsibility for the crash, even if it means > responding to lots of bogus "bug reports"... from the other thread on the musl list right now where someone doesn't realize they need to type `run` in the debugger, i'll let you draw your own conclusion about how successful i think that's likely to be :-) the trouble with the "someone's wrong on the internet, i must correct them" approach is that it doesn't scale... but, yes, we've had some value from a related idea of having the software that generates a crash dump do the "first level triage" of a crash and explicitly say things like "null pointer dereference" or "this code aborted --- see if it logged anything first" and so on. > Rich