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=-4.8 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23898 invoked from network); 15 Aug 2020 00:47:50 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Aug 2020 00:47:50 -0000 Received: (qmail 9879 invoked by uid 550); 15 Aug 2020 00:47:48 -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 9858 invoked from network); 15 Aug 2020 00:47:47 -0000 To: musl@lists.openwall.com References: <20200814214136.GP3265@brightrain.aerifal.cx> From: "A. Wilcox" Autocrypt: addr=awilfox@adelielinux.org; prefer-encrypt=mutual; keydata= mQINBE+DjPIBEADTQ1H/e/avDUhgt8+T3TJpjGYoY9Y47EMfHqWMm9LjR9aiZSG6GWRbpjWS 4V0DqzIhNQw7HLkPws9CVqQkmpIeltQyGDV2qcR5AXxJ4lCRWHxwRzWE0cCzhLUR9BBWOO0U NINQY+2IqmzRAqXZ9zL+mGTles/qeheXmaWLKf/T0kqJFihoM+ItQvUWOkWUdVv0prhzXr9Q QUdt0NTIW8n4sPwtuSvQgqwSzCJQArh1myugVSGiIIN38pCU8g41Vh35mHHhbHjbn0o1mhrX B/gbsndGo7QQBKz4CPaSel+Fl92dCvVWTp1XYyjqeZx2xlx1zfDrXOTuzY1WmNHi7BgHYuem tG7Zyp7u9MR6FvLKgQhmvCQZXaa+9oNtwKckxoP/I5R8ede9YRb6pLyG5JC0pTTk7kpUZCX2 tm8pLKy899zomm8BBm71aEJHE44ABEl/PbM7tA7XhSPiWsdBmVCxH4bqpUgGMx0ztqhNsUul SDDhiAWgtYFHATynhmeKBDKthkO7lj4CzwI54dn1uiwDtvUFVyVsPMjJcCxFnONbOPcvm1R9 sDg5sn57dv0f+EtaU3ppZdotutjM9X7OEC93d1flO3k1LO20qn2ZcI24f3tEOLAjn5xZ1GdV 3BYBwrtuaaiO8tMdp0uAtILzkkrcr0vOi2/SngxtXFw+44X+WQARAQABtDNBLiBXaWxjb3gg KEFkw6lsaWUgTGludXgpIDxhd2lsZm94QGFkZWxpZWxpbnV4Lm9yZz6JAjoEEwEIACQCGwMF CwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlhEpGYCGQEACgkQyynLUZIrnRQu5RAAqxHJdNIQ ucYYUaYX4EHJte4OAZbxXeGgMi4fe4m2qkMrd8U6VDfRbjsqETK7fOJdrIjvp+xrMTMvj36C LZ5YuBVmvTd4+Qn54y+8doMUtZppjW9Njwols3zCeaZR/4Iid2GjS7+avgVEhMuxlo5apygb n84VhdLRPAs2BtyqUWUhlLs2nXg6kzI/yT8frGGCN36Xewe35jrhl7h4d54t7h+wYcYw52Yt GHs/R+yPlCGPrlzh8IGwjDWDaUrQAqWdU3B2UG4g/yn/JYZrkvfbm7AhpBP5trY2jbm7sfTM NoClDDwgf0K8Kfj0LeBUzOLqGgQNBdaJ2x7f1xq5tJjAPmVL6oMElqyDz9ycUXvelLMnxgXI sjndF+K1aKjg6Ok68BfTo+tnUqmEjqAhjLBCSphQJavww8pU9KSPmxOr0GfjoiYELeoCdTe2 U44bhFwCcf5tG1qdu8l4pes1YPRVAVyr4J/BlS2e3FyU3MsYlma9toYghJZ0k9dVOqx5YXj9 B2keDpX1D7uEJUHpoRSPylLYKJCcNuzrsaK0gvczkgUvhaiij8qnlLEmDsv7KMdsv+qxknNC vdCBgoiYn01ZJZJrlllOEXpVAXfQDKcqGnIJ4GX87TIu3hR94tw4LOCayfRpN2Y4zlACPLaZ KiSon4ySDo+ooYQ8WgwH1y1ESsa5Ag0ET4OM8gEQAOI/n9h9v2TBOiLUt/nL+HOdxqvkfrKp mDHXx6ctJSm0VBHhHCxKN6Tk2B0BsUXcgR+BD76Tw4kTQvuj3E87m13xHRtASdCmnkvGhU4c JJ9ZbJbJhPLNr9qPUxwCQxFyMrFri/9GnE0Kbv5FfxsLQy9Slubnyg3CfI/wIP5pOoVFA2qI UmsQS155DmhbV2m0FDf0san01ZRMFYVcUUktcmFo0Xmr6PAxZ0FTaxSF8+921lKrvShcsnMv Osrf5toJGEdQw/IMO5rKH1m+q3qWQAOw4uF4WQJrGvhEsVK8G4mC6EBDTbxFVDtyBTMAGUVS t+Yb5i0iIYiMAP2MEJ+twg58PV+5RglheTGP9iPW0xReI1sOD9jfIrQbwqWpOchDGBUpQx4q DFYzzcbjvAP1k2o0mwMby5DJlVwktUiXXtOWZXKZXfTnCA65x1bC6gbtMrXN1CWkyjKT9xj9 Z5WlpZaeqe2SZkLG3/N7r4bSbw/Z6NsYeJ8CpSe6SfoWSsjebD6kbXlF5dsQf8aMUjaZAHp0 UpinfgWNh+58128yddsRMsidjU/MmwhzcRFsvn3rkgtnK4IwpLEfssChNPa26qwfcsvQ+AQU CCRd/GIZ8AkOVySQ30J8Assa/T3nc6VNKRVgsAiSClkeqVevAZmUMUbvH8f3cTe1VFn6kR3q pvfTABEBAAGJAh8EGAECAAkFAk+DjPICGwwACgkQyynLUZIrnRQifQ//f++reIP4el9Un1w4 11boSy1iBALnv58YSQQHPIZ4dq5hr8P1Hp3GDz+o6JFKeIHq5RYw2ornumS9waDbz7dRD1nc N5sMoVfR2g2P7honq59r3velxX36PmifHMmxb8MTqbCSJJRisqjWTMg7CZxH0NQ28qMtpiAw kvoEb+l2Uc/gKnvcpPfVJ/X0b3go0xAe9GA7Os9thjtl1v+I7c2+xjPUtvv+pDGRb9To2+Sw zOGwogbTrVw7KgAFhktx6i8tenXZRf36O0GTACRY//qHNoNNy5H4LYmfyHj6VU2ehwNJTlkK H/8oYV7fkOdcs6DZAnxeiOXUKpHC6ck0D0sWQ42GTeEraospQevGTrp1FZdYnfXznUFXuC6W jHR9piQehutMJ1vCP+DIRLGOMzV1TFWflpo71lb4AFLU3UOS/N7Cd8F+w1nG3WPn7UjFCMrc Xf268AEe0xwakXgNtwo2MTbtQSAO5AKYyGm/hnoLZg4YQ2eBPU95jUV+GMoEM/8Q0BJgsyF0 66NfhBXtuo50AipcARmnoqi6NDOKpC6mqiEYGsVuyQ9cRtkk9Jl98tXmnjxQlSL2nb4ErwJJ SyJq3hwiKMUJcw88IRNtYBe+dXaW4kDBTRha1k+brWZbu4tUlRWLVcSGjtP1pVukXA/SQ6a1 N7qhRF0UHQZkMW1rGbU= Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <45ce1753-52ec-5890-58c1-5350cb6c8c39@adelielinux.org> Date: Fri, 14 Aug 2020 19:47:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200814214136.GP3265@brightrain.aerifal.cx> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FjjXXc63kDE12PokeD24aPFTIoH6Ymonq" Subject: Re: [musl] Restrictions on child context after multithreaded fork This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FjjXXc63kDE12PokeD24aPFTIoH6Ymonq Content-Type: multipart/mixed; boundary="gmxcHhE6KebIFUQMY8LK1cBcbpdearwCM" --gmxcHhE6KebIFUQMY8LK1cBcbpdearwCM Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 14/08/2020 16:41, Rich Felker wrote: > musl 1.2.1 has exposed bugs in several applications and libraries > caused by async-signal-unsafe code between (multithreaded) fork and > subsequent exec. So far, dbus library code, pulseaudio library code, > and libvirt have been found to be affected.=20 >=20 > Fixing the affected library code looks very straightforward; it's just > a matter of doing proper iterations of existing data/state rather than > allocating lists and using opendir on procfs and such. I've discussed > fixes with Alpine Linux folks and I believe fixes have been tested, > but I don't see any patches in aports yet. Over at Ad=C3=A9lie we've been monitoring the situation intently. We're = not bumping musl to 1.2.1 until we have time to do a full tree test (similar to time64) due to this. Fixing dbus and pa are on my list of post-1.0 things to do, since they are so vital to modern desktop usage. If someone else patches it in the meantime, that's even better. > I've seen suspicions that the switch to mallocng exposed this, but I'm > pretty sure it was: >=20 > https://git.musl-libc.org/cgit/musl/commit/?id=3De01b5939b38aea5ecbe416= 70643199825874b26c Doesn't make sense to me. We backported that to Ad=C3=A9lie's musl 1.2.0= package the day it was committed to musl, and Firefox has been rock solid for me for months. No deadlocks, no weird behaviour. Similar with other apps that use D-Bus and Pulse. At least on ppc64, x86_64, and aarch64 (my daily driver arches), it's been through almost three months of usage without issue. Perhaps it's the mixture of that commit + malloc-ng? > I'll follow up on this thread once there are patches for the known > affected libraries. Thanks! I'll do the same, if I manage to write patches. > Note that this is a type of bug that's possibly hard to get upstreams > to take seriously. libvirt in particular, despite having multiple > comments throughout the source warning developers that they can't do > anything AS-unsafe between fork and exec, is somehow deeming malloc an > exception to that rule because they want to use it (despite it clearly > not being necessary). libvirt already isn't usable on musl, so this isn't really something we are going to spend any time on. Others are free to do it. > And the dbus issue has been known for a long time; see open bug: >=20 > https://gitlab.freedesktop.org/dbus/dbus/-/issues/173 > (originally: https://bugs.freedesktop.org/show_bug.cgi?id=3D100843) >=20 > This is largely because glibc attempts to make the erroneous usage by > these libraries work (more on that below). >=20 > The next issue of POSIX (Issue 8) will drop the requirement that fork > be AS-safe, as a result of Austin Group tracker issue #62. This makes > the glibc behavior permissible/conforming, but there does not seem to > be any effort on the POSIX side to drop the requirement on > applications not to do AS-unsafe things in the child before exec, so > regardless of this change, what these libraries are doing is still > wrong. >=20 > In order to make the child environment unrestricted after fork, either > fork must hold *all* locks at the time the actual fork syscall takes > place, or it must be able to reset any state protected by a lock that > was held in the parent (or some mix of the two). It's fundamentally > impossible to do this completely (in a way that lets the child run > unrestricted), since some locks in the parent may be held arbitrarily > long such that fork waiting on them would deadlock. In particular, any > stdio FILE lock may be held indefinitely because there's a blocking > operation in progress on the underlying fd, or because the application > has called flockfile. Thus, at best, the implementation can give the > child an environment where fflush(0) and exit() still deadlock. >=20 > In case we do want to follow a direction of trying to provide some > degree of relaxation of restrictions on the child (taking the liberty > of POSIX-future drop of fork's AS-safety requirement), I did a quick > survey of libc-internal locks, and found: >=20 > - at_quick_exit > - atexit > - dlerror > - gettext > - malloc > - pthread_atfork (already necessarily held at fork) > - random > - sem_open > - stdio open file list (vs individual FILEs) > - syslog > - timezone >=20 > This list looks tractable. Aside from malloc, whose locks would need > to be taken last since the others may call malloc, these don't seem to > have any lock order dependencies between them, and each one's lock > functions could be provided as strong overrides to weak no-op > definitions in fork.c. Some of these seem more important than others. Including the list in your follow-up, I would say a priority would be - malloc - gettext - random in roughly that order. That's just based on my experience with these not-great codebases. Best, --arw --=20 A. Wilcox (awilfox) Project Lead, Ad=C3=A9lie Linux https://www.adelielinux.org --gmxcHhE6KebIFUQMY8LK1cBcbpdearwCM-- --FjjXXc63kDE12PokeD24aPFTIoH6Ymonq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjNyWOYPU1SaTSMHHyynLUZIrnRQFAl83MKAACgkQyynLUZIr nRT81Q//Vy+Fioug4gB3NXXQsLQgri4CNHeYTvLqs3m/nelMZSIQhqOUzKt0OwGq TefaYaP3pp6c17wG/qdYBusl//0KHhGQ5/+/unKHtqkpBMPjNChJhF1Tmq1RuxKl 8Z47zaxNSS/AjXzlSaLgVkYPxZ/QE9fyzRdxhxaS8JEDwfuCaXk4/uuVwytFAR3N WSR46FNA37UeQZel/FXqDZ8YSgK/X2yaypAGb32B0ipHD6Qmgw4KmxdsSOwql9LN 0WpqlBDgMahqVDWSRR+YZ1ngBuS7fvsuNQ7TFG3bHNZWXmbi0cIWvEhpC+dy95A4 41BWHQWR/O53V97tdFTVu51Ef6kxVM0luvz85joGsaWnmK/G+hjpmdtM7bQo+7u2 Loj1MOPDfYbN13IJO0xGJEKuHNqf3mogppoxBzRgjI562uh9fAO+bKKEc0Mr18kx xa/tkEJSq1pE5/j+zOsdLHAjsR6o441cIKaSpszFs96hQM0cMWfosC+aPy/UTJvM k4iKJFomFi5jthXlV4jN4BKJbYFRbtM/cdmOkjlQqMRydBSxAGYlqlnoMHbgTgLR i3BCLvQIdpB2OPoG700X8X9KzNQ8O3m9flH8t04AJdsJ4szmAtXBRUMLPLeuFO4X DOrWcSRwvkoj2ASxExlCeU2RHyQeLeTF8BrN/sIXGWCJN7Nvs0k= =KjeJ -----END PGP SIGNATURE----- --FjjXXc63kDE12PokeD24aPFTIoH6Ymonq--