From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F407B3858D37; Fri, 3 Mar 2023 12:36:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F407B3858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677846973; bh=ujso2bNcau8nn8SLLMjk/4gTOAgcC+BiJ+jJiZ50K00=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ewuiIJn0RmSlqnU74hUlhFnbhK29ZEe6obWpeiyB/XzPoBFKxLCAfh8qEknPqSPyQ n1Ie6DjucbPtnQ1ppPFznKpbf8aGR1e9gUsVkG4zX/gMGv2ECuiIpnPnOPXaZ+CXuS bFz73gvgwq2OxAvB1xXGDop1chxsmJWLfj9TBls0= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30127] [rfe]: enable ld audit at run-time Date: Fri, 03 Mar 2023 12:36:10 +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: stsp at users dot sourceforge.net 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 #34 from Stas Sergeev --- (In reply to Jonathon Anderson from comment #33) > So, my group currently assumes la_objopen() happens before the init > constructors of the referenced objects. It turns out to be an important > callback for registering callbacks in runtime libraries before transferri= ng > control back to the application. Is there a way to indicate to the auditor > that it's "missed the boat" so auditors that need this timing can recover > gracefully? Sure! The sale point of that patch is to allow more convenient ways of communicating with an auditor. So of course there is such a way! In v9. :) > Why would you have to lift the variables in the legacy code? Those are > already "inside" the VM, right? No: VM is a part of compatibility layer. It allows those solibs built from ancient non-unix code, to work. And shim is gluing these 2 components together. So if solib calls something, shim forwards the call to VM, but the call args must be all accessible to VM. So the libs are mapped to the 4Gb window where VM can see them, and that 4Gb window is not in the lower 4Gb, but rather somewhere in a 64bit space. > What it sounds like you're trying to do is pass a pointer to the data > segment of a 64-bit library "outside" the VM to the 32-bit legacy code > running "inside" the VM. Which it will then dereference to access or alter > some variable shared "across the VM gap." Does this match your use case? Indeed. > If you control this 64-bit library, you should be able to lift the shared > variables to pointers. Just allocate them "inside" the VM's more restrict= ive > address space and reference from "outside." In this case Glibc doesn't ev= en > get involved. I still don't see how can this be done w/o rewriting the libs from scratches - the ones I do not control, I only have the control over the shim lib. Now suppose I do have a control over the actual solib (actually not, but if), and then what? It can do thousands of calls, any of them can have pointers to its own local or global data, variables, whatever. I do not control these libs (the compatibility layer is the final product, libs are on user's side), but even if I do, I would have to walk through all its intercepted calls and convert all referenced objects to a heap objects - heap objects can indeed be allocated on the VMs side, and in fact, the heap objects _will_ be allocated on a VMs side. But I can't estimate the work of converting all addressable objects to heap objects, even if I could control all those solibs. > The only reason you would require dlmem() or la_premap is if you didn't > control the 64-bit library who's data segment needs to be shared "across = the > gap." Is this the case? Yes, it is the case. I only control shim lib. But I don't believe even the "otherwise" would help much. Compatibility layer that requires you to rewrite everything, is not of a big use. > The result of the first call to mmap() for an solib decides the base addr= ess > for the solib, which is the address all relocations are relative to. Its indeed the nice trick, but the problem is that I need a "disparity" between the relocated and mapped address. Relocated address is in MAP_32BIT, but mapped address =3D relocated_address+VM_window_start. Then VM sees the solib in its relocated address, which is the goal. > There's a performance penalty to syscall wrapping (and it's arch-specific > and ugly), but AFAICT it should work just fine for this case. 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? Esp given that there is a demand in a functionality of specifying the relocation address, it can be found on stackoverflow. There were multiple requests for dlmem(), too, both here and on steckoverflow. There are even some sketches on github from various people. And finally you can also have that feature of "mmapped_addr!=3Drelocated_addr" - all by the price of 1. :) Why even try to replicate that with tricks and hacks? But I think its impossible w/o my patches, anyway. --=20 You are receiving this mail because: You are on the CC list for the bug.=