From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B32943858C52; Mon, 13 Mar 2023 09:41:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B32943858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678700492; bh=xrFmnKLrnxRFCEpWOMWnqDMXYYqFo2JmRqqq8Uwsf9o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kyhP6yRhZNYSzwicpbk9s7jH4FAV4ZqqlcdJLyeFgHtTBp8KD7DTXry+TuxwkMwFy zq7gLOnDtczNM0ab7kG4eg8P0EM4UFxxKmROJKnMPp1SrCQjaQbcRwC42356CobGgQ S2gCaV2ESVBt5+c2uN6cClxSZNZkmqDg2KF9W1aM= From: "janderson at rice dot edu" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30127] [rfe]: enable ld audit at run-time Date: Mon, 13 Mar 2023 09:41:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.38 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: janderson at rice dot edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30127 --- Comment #43 from Jonathon Anderson --- Going back to your use case: (In reply to Stas Sergeev from comment #37) > > I assume there's a Very Good Reason (TM) the ancient code can't be comp= iled > > 32-bit (and run in the VM) nor the compatibility libraries compiled 64-= bit > > (and run without a VM). Otherwise you wouldn't need any of this. >=20 > No, this is not the case. :) > I mean, the reason may be not Very Good (TM) > for your ears, but its just that it would need > the pretty much outdated tool-chains that no > one has these days.=20 I can consider that a good enough reason not to compile the ancient code as 32-bit. But the compatibility libraries are surely much newer, can't they be compiled 64-bit? > Also the ability to work > on host in 64bit mode provides performance and > other benefits.=20 It does. Can you compile the compatibility libraries as 64-bit instead? :D > VM is much, much less involved > in that scenario, than when you run everything > inside VM. In theory, this will also allow to > extend the old code with some functionality > available on host, but that's not something to > anticipate at that early stage of a development. >=20 >=20 > > What do you do about pointers to stack variables? >=20 > I can set up the initial stack from my > shim lib, and if an app wants to switch > stacks (which is very unlikely), it will > have to use the heap space, which is under > my control. How? The initial stack is set up by the kernel before the executable is even mapped. Do you switch stacks in your shim library, after the VM memory regi= on is decided upon? While on the topic (and mostly out of curiosity), what do you do when the 64-bit code allocates more than 4GB of memory? It obviously won't all fit in the VM's address space, so a pointer could be passed through the shim lib t= hat would end up out of bounds. >=20 >=20 > > That... makes absolutely no sense. In that arrangement the loaded solib= will > > be useless outside the VM, the relocations are wrong for the 64-bit add= ress > > space. >=20 > la_premap_dlmem() is a very powerful extension. :) > It allows you to map the lib anywhere you > want, any amount of times in a row. You can > map it to VM window _in addition_ to also > mapping it to its relocation point. That's > what even the test-case of mine demonstrates > by doing 2 mappings of the same lib.=20 ...If all you wanted was to mmap the solib to another address, you can alre= ady do that using mmap and /proc/self/map_files/. Maybe dl_iterate_phdr. No la_premap or dlmem() needed. The only reason any extension to Glibc is needed is if you wanted (reloc_base_address !=3D mmap_address). Which, to reiterate, is completely nonsensical. >=20 >=20 > > So why does the 64-bit ld.so need to load it? Can't you load it > > inside the VM using the 32-bit ld.so, since that's the only place it co= uld > > possibly work? >=20 > It should work in both "worlds" because it has > the regular DT_NEEDED deps linked with its > own custom libc. So the host relocations should > work properly, and only the shim lib translates > the calls into VM. I really don't understand. The ISA is different between the "worlds," the relocation base address will always be wrong in one "world" and make the so= lib useless there. Heck, even the ELFCLASS is different. I see no way for an solib to function in both "worlds." AFAICT the best you= can do is "manually" (i.e. not via data symbols) access the data segment from t= he "other world," functions simply won't work. >=20 >=20 > > > I don't think the proposed scheme can be > > > replicated by any tricks and hacks. And > > > honestly I don't know why it should. > > > There was that LD_PREFER_MAP_32BIT_EXE but > > > it was dumb, so removed. Why not to replace > > > it with something small and smart? > >=20 > > IMHO this is well outside the kinds of problems where a "small and smar= t" > > solution is a tractable goal. After all, we're talking about multiple > > architectures in a single process image. :P >=20 > I think LD_PREFER_MAP_32BIT_EXE was also > about something like this. So my demand is > definitely not the first one. > But let's look at it from another side: > all I do is specify the reloc address and > pass a backing-store fd.=20 You can specify the backing-store fd with classic dlopen and /proc/self/fd/. That's a very simple solution, and requires no changes to Glibc. You can choose the reloc base address (=3D=3D mmap address) by overriding m= map. That's not a simple solution, but it doesn't require a new interface or Gli= bc patches. As noted above, I'm not yet confident your use case would work eve= n if you could specify the reloc base address. I don't see any reason to support the (reloc base address !=3D mmap address) case. It's utter nonsense. (In reply to Stas Sergeev from comment #38) > So dlmem was requested: > https://sourceware.org/bugzilla/show_bug.cgi?id=3D11767 > https://stackoverflow.com/questions/5053664/dlopen-from-memory > https://stackoverflow.com/questions/29637464/need-an-api-that-allows-me-t= o- > load-a-shared-object-from-a-memory-address >=20 > And even implemented: > https://github.com/m1m1x/memdlopen AFAICT these discussions are all solved by memfd_create. Almost all of the complaints revolve around the memory vs. disk performance difference, memfd_create is a very easy way to get a memory-backed file on modern Linux boxes. >=20 > Mapping to specific address was requested: > https://stackoverflow.com/questions/62064806/is-there-a-way-to-specify-th= e- > base-address-of-a-shared-library-using-dlopen I'm as confused as the answer's author on what the OP's actual use case is here. Given the OP's lack of response to the request for context, I wouldn't consider this worth much attention. --=20 You are receiving this mail because: You are on the CC list for the bug.=