From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by sourceware.org (Postfix) with ESMTPS id AB9FF3858C54; Fri, 12 May 2023 14:21:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AB9FF3858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=samsung.com Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20230512142115euoutp02d8fcf7a97bbe941974639b1d81e758b9~ea0m15TX01492514925euoutp02Z; Fri, 12 May 2023 14:21:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20230512142115euoutp02d8fcf7a97bbe941974639b1d81e758b9~ea0m15TX01492514925euoutp02Z DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1683901275; bh=1Qws07LgXRM3b2mA80NSri99VU8UMA4X8ja2zW55vaE=; h=From:To:Cc:Subject:Date:References:From; b=IwN1D/IEHWiEqmKn/biQGm73yGZjg41Qe3DXwNnhzA2Pni76Xvrgomz25hyo57LXd EV+7AASyAbJduFLabVo52jzAr8h9kF3xidbJU4eF6eodkmoDK7ZPNIXUhMAekU1Lm4 Kiy/qj7OJzN5GIAwo43gm6UIsQjLUWMRc3L5dPY8= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20230512142114eucas1p2a5cb60b5d7136048a73ea1cece9cfff4~ea0mlsQaa1781717817eucas1p2u; Fri, 12 May 2023 14:21:14 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id 9D.29.35386.A5B4E546; Fri, 12 May 2023 15:21:14 +0100 (BST) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20230512142114eucas1p112d969a89ad2480a0c10a532bd6d8440~ea0mN3gzx1312813128eucas1p1t; Fri, 12 May 2023 14:21:14 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20230512142114eusmtrp230e2e96604120663f637f83512695d2c~ea0mNBZtH0367303673eusmtrp2R; Fri, 12 May 2023 14:21:14 +0000 (GMT) X-AuditID: cbfec7f4-cdfff70000028a3a-a0-645e4b5ad195 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id DD.4D.14344.A5B4E546; Fri, 12 May 2023 15:21:14 +0100 (BST) Received: from localhost (unknown [106.120.51.111]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20230512142114eusmtip22e592984c6ff65d5e1b8772ecfade7e5~ea0mCRx8g1353613536eusmtip2H; Fri, 12 May 2023 14:21:14 +0000 (GMT) From: Lukasz Stelmach To: libc-alpha@sourceware.org Cc: schwab@suse.de, maskray@google.com, fweimer@redhat.com, palmer@dabbelt.com, adhemerval.zanella@linaro.org, joseph@codesourcery.com, binutils@sourceware.org, Marek Pikula , Marek Szyprowski , Karol Lewandowski Subject: global pointer gets overwritten with dlopen(3) on RISC-V Date: Fri, 12 May 2023 16:21:09 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHKsWRmVeSWpSXmKPExsWy7djPc7pR3nEpBldb1C2m7l/GZPFx2h5G i+9zdjNZHP7QyW7R+Gkus8XvezvZLP7Om8pmsfbIXXaLf7d2slq8vNzDbHHyTQ+LA7fH95cr 2TzevHzJ4rFgU6nHnWt72DwOvtvD5PF+31U2j74tqxg9tv9289h8ujqAM4rLJiU1J7MstUjf LoErY/oez4LdshU/PjxnamDcItHFyMkhIWAicW3WG+YuRi4OIYEVjBINb9ZCOV8YJdZc2MQI UiUk8JlRYv6WBJiO3itdbBBFyxkl3m84zQZR9IJR4sZWpS5GDg42AT2JtWsjQMIiArISix5e AhvKLLCBSWLeqj6wemEBR4lTczaxgtgsAqoSHf0tzCA2r4C5xIPlh8BsUQFLiT/PPrJDxAUl Ts58wgJiMwvkSsw8/4YR4qDJnBKTv4VB2C4Sh5b8ZYewhSVeHd8CZctI/N85nwnkCAmBdkaJ pisLWSGcCYwSnzuamCCqrCXunPvFBmE7Snw7fIEd5BsJAT6JG28FIRbzSUzaNp0ZIswr0dEm BFGtIrGufw8LhC0l0ftqBdRtHhL7T1xnhoRPrETDhvWMExjlZyF5ZxaSd2YBTWUW0JRYv0sf IqwtsWzha2YI21Zi3br3LAsYWVcxiqeWFuempxYb5aWW6xUn5haX5qXrJefnbmIEJrPT/45/ 2cG4/NVHvUOMTByMhxhVgJofbVh9gVGKJS8/L1VJhPftkugUId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rzatieThQTSE0tSs1NTC1KLYLJMHJxSDUzsbxrvP7358UqwrMrWnnkP6kWuOgUbuiWw 7WWzn/HGRTLOepvCr2e1ay4endS0Sa7O69Lfa/9PTDRl8DU8Pk+d4937SlPl0l9/WiPOJLS3 tSi37un0du/MexmY26ildEHeVTMhNyS3qcrUJ3CDWvMNs/M8x1QfiO54nZF0tikocoav5fz6 3hMzN7se/bxT0ulpy4TVuYdPKPBs0s0wrOBt9XmhlLhp1t/ZRqxrf0t7cpfNujRXx35mt/e+ 1NUvrjBZ8n0K8LacWPhoW/juR7F9UocKitgvZd8NuLWOydGgiqu86tOka98zHiQz3TvG6ZDM Msfo/zpVtzdfluVmlty9/P7SQ3sV42Kd1bVbbZRYijMSDbWYi4oTAeIWAv3hAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsVy+t/xe7pR3nEpBv9u8FtM3b+MyeLjtD2M Ft/n7GayOPyhk92i8dNcZovf93ayWfydN5XNYu2Ru+wW/27tZLV4ebmH2eLkmx4WB26P7y9X snm8efmSxWPBplKPO9f2sHkcfLeHyeP9vqtsHn1bVjF6bP/t5rH5dHUAZ5SeTVF+aUmqQkZ+ cYmtUrShhZGeoaWFnpGJpZ6hsXmslZGpkr6dTUpqTmZZapG+XYJexvQ9ngW7ZSt+fHjO1MC4 RaKLkZNDQsBEovdKF1sXIxeHkMBSRokDMx+wdDFyACWkJFbOTYeoEZb4cw2m5hmjxJJlHWA1 bAJ6EmvXRoDUiAjISix6eIkZpIZZYBOTxJMVx1hAEsICjhKn5mxiBbFZBFQlOvpbmEFsXgFz iQfLD4HZogKWEn+efWSHiAtKnJz5BKyXWSBb4uvq58wTGPlmIUnNQpKaBXQGs4CmxPpd+hBh bYllC18zQ9i2EuvWvWdZwMi6ilEktbQ4Nz232EivODG3uDQvXS85P3cTIzDmth37uWUH48pX H/UOMTJxMB5iVAHqfLRh9QVGKZa8/LxUJRHet0uiU4R4UxIrq1KL8uOLSnNSiw8xmgK9M5FZ SjQ5H5gM8kriDc0MTA1NzCwNTC3NjJXEeT0LOhKFBNITS1KzU1MLUotg+pg4OKUamFSuXnFn Kd7Ufv2Zi1+plKxNf+DP83dfvZn6e0uyypKV9caPD7FO/3Sw9FqZdl7lZ/2Z/t+PSGbt9K1L Kbn0eLLR1ry8fyxvbyxYfMpqV8v6F87ct3+fM34Y9vvHqtLsKIlLDZP6Fgsccd2ePK1P7YHR JineVVtlZAMaF92K/r03sEVcIbKi/4SQ+Nz1j7mSVb/d1FzgLd5kk37jWRCfYMDDB8c3zRUw n7MluDtctjmn8ZTb+jgm8XkryqzkfH+ufPiak+eaba4Z88cq1kAlyYPmZ1a3M2sEXjJJ7+p5 MGnTgzfr7sxKjJ87cZvhzjMLRH4tPM9jlbN5dvqib2/9jXsXdCr/YvU7MunI643F5x2VWIoz Eg21mIuKEwG5cU0nTgMAAA== X-CMS-MailID: 20230512142114eucas1p112d969a89ad2480a0c10a532bd6d8440 X-Msg-Generator: CA X-RootMTR: 20230512142114eucas1p112d969a89ad2480a0c10a532bd6d8440 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20230512142114eucas1p112d969a89ad2480a0c10a532bd6d8440 References: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, We've encountered an issue of a program misbehaving due to its gp value being overwritten. Let me present our setup and the exact sequence of events. We've got a program (the testee) written in C that we test with another one (a testing harness, the tester) written in C++ with gtest. So far, so good. To make the testing and inspection of the internal state of the testee easier the tester does not start the testee as a separate process but loads it with dlopen(3) and calls the testee's main() function. Data structures of the testee get initialised but the main() exits (as desired) due to some unmet requirements. But this is fine. The code of the testee remains usable and the tester starts calling it function by function. Alas, this is the point where things go south. What is worse they do so in a semi-random fashion. We've seen several different behaviours they were consistent between runs, but sometimes changed after compilation. Long story short, both the tester and testee were compiled and linked with relaxed relocations turned on. Both chunks of code assumed different value of the gp register, of course. What happens =E2=80=94 step by step: 1. The tester starts and sets its the gp value in _start (see sysdeps/riscv= /start.S) 2. The tester loads the testee with dlopen(3) 3. The dlopen(3) calls load_gp via preinit_array (see sysdeps/riscv/start.S) 4. The testee's code works fine, because the the gp register holds the value from loaded with the testee's load_gp. 5. The tester's code fails in many curious ways (e.g. stdio doesn't work, different functions are called than were supposed to because ofoverwrittent GOT entries etc.) Even in situations when the tester didn't fail until the end of its main(), it always caught SIGSEGV in __do_global_dtors_aux(). Our fix was to link the tester with -mno-relax option set. And it worked. However, it took us a few days to understand all the details and we think something needs to be done to avoid the confusing semi-random failure mode even though we recognise our use-case is somewhat unusual. Possible general solutions: 1. Make -mno-relax the default for ld(1) (on Linux?). We have no benchmarks whatsoever, but global variables aren't very popular in application code these days and the gp register allows access to a single memory page (4kB) only. No big deal really. 2. Make dlopen(3) (or any appropriate piece of code deep down in glibc) recognise the situation where the gp has been set and may be overwritten and report error. Neither overwriting the the gp nor loading a binary without (e.g. removing load_gp from preinit_array. why is it there in the first place?) would give us a working code. The above solutions aren't mutually exclusive and implementing both of them seems like a good idea. Are there any other ways to avoid misbehaviour when a process dlopens an executable binary and calls its code? Kind regards, =2D-=20 =C5=81ukasz Stelmach Samsung R&D Institute Poland Samsung Electronics --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEXpuyqjq9kGEVr9UQsK4enJilgBAFAmReS1UACgkQsK4enJil gBBG1Af+O9nNWe9UFBV7lOKc17UWo1jtv3aRox7iGjJ2c+58OTSQ+u7RJShIn5Bo X3dadX/gYWWVdoLD5C4CaOlGp6uw6MpPEchnGOwW4UaWYLctxigkq04RUjwYh6tU uxfRsbuZKNOxGwwX7Nx+oVcW82aCxxKg/ic4VI2VN1SjGwZFaZaXp8nBYKzeMsOu u+bRqI9wPUxb59XVfB00e51P+7bpulKhBhYFSSuk36M3C83S0V/kOKTs4fAXGEod xAUG75yLDfhHb44W7xue1muRkAy+Zdj8WXFkjHOkFQ1qCXL1tXZ3SZwb+S8Msdzv n7P54W12tKujr3e/J0w6H8I3qfWxdA== =tdOR -----END PGP SIGNATURE----- --=-=-=--