From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AF4393858D39; Mon, 6 Mar 2023 09:12:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AF4393858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678093935; bh=SLNLuR+eqa6hqaiRsIkMLbk8+JHNY4ZvHdfEqpLUQWc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ydfzklzVxlTwkPgvLVSpvg0Aa1Zv9US9zlReTBmgXDiGU0vhg+s4DPC7JqsMu1CVZ W28BV8knt6vXksGYiLZo8m027LMbJDTyKJxrxTUhf6RFjm+vssHn7Rr/qe7jatFqvE kuGn1VsCXCWRAHqhUuCPhbLLJJN2A26pA15bk9PQ= 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, 06 Mar 2023 09:12:11 +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 #36 from Jonathon Anderson --- (In reply to Stas Sergeev from comment #34) > (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 transfer= ring > > control back to the application. Is there a way to indicate to the audi= tor > > that it's "missed the boat" so auditors that need this timing can recov= er > > gracefully? >=20 > 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. :) I must not be seeing this feature in the patch. Can you guide me a bit? I s= ee la_dynload which indicates when an auditor is dynamically loaded, but AFAICT there isn't a way to tell which la_objopen callbacks are "real" (new object= s) or "fake" (objects already loaded). I probably should have been clearer in my request, sorry. (In reply to Stas Sergeev from comment #35) > So while I added what you asked for, > let me wonder why "missed the boat"? > It seems gcc allows to specify the > constructor priority. So why not to > create the "first" constructor for > loading audit modules, How does that help? Constructor priority means nothing after the solib or executable is linked. GCC/ld uses the priorities to sort the list of _init functions within a single object. ld.so decides on the order objects run th= eir constructors based on dependencies between objects and nothing else. (In reply to Stas Sergeev from comment #34) > > Why would you have to lift the variables in the legacy code? Those are > > already "inside" the VM, right? >=20 > 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, So, let me just make sure I'm on the same page here: you have non-Unix (or = even pre-Unix?) code that's been compiled into 64-bit solibs. And you have compatibility libraries to implement the non-Unix bits, but they're 32-bit = only and so need to run in a VM. So to get everything working, you need those two kinds of libraries calling each other despite the complete ABI and ISA difference, in a single process. I assume there's a Very Good Reason (TM) the ancient code can't be compiled 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. I'm not confident this description is right based on your comments later...= but dang, this is quite a unique problem. > 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. And the call args can contain pointers, thus the need to ensure the pointers are in range. You can override malloc and new to (mostly) ensure heap allocations are in the right region. The dlmem/la_premap patches(es) ensure pointers to data segments will work. What do you do about pointers to stack variables? > > If you control this 64-bit library, you should be able to lift the shar= ed > > variables to pointers. Just allocate them "inside" the VM's more restri= ctive > > address space and reference from "outside." In this case Glibc doesn't = even > > get involved. >=20 > 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. I'm beginning to understand this. If so, the question is indeed moot. >=20 >=20 > > The result of the first call to mmap() for an solib decides the base ad= dress > > for the solib, which is the address all relocations are relative to. >=20 > 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. That... makes absolutely no sense. In that arrangement the loaded solib wil= l be useless outside the VM, the relocations are wrong for the 64-bit address sp= ace. 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 could possibly work? This seems to contradict your prior explanation too. Doing this will make a 64-bit solib useless, the relocations are wrong in 64-bit address space and= the 32-bit VM can't run the code (wrong ISA). If you don't fully control the 64= -bit solib you're doing this torture to, there's no way you can expect this to w= ork at all. >=20 >=20 > > There's a performance penalty to syscall wrapping (and it's arch-specif= ic > > and ugly), but AFAICT it should work just fine for this case. >=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? IMHO this is well outside the kinds of problems where a "small and smart" solution is a tractable goal. After all, we're talking about multiple architectures in a single process image. :P > 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. Mind providing a couple good sources for what you're referring to here? I didn't get any relevant hits for "dlmem" on these sites or on Google. > And finally you can also have that feature of > "mmapped_addr!=3Drelocated_addr" - all by the > price of 1. :) That's the part that makes no sense to me. Why would ld.so EVER load an sol= ib in an arrangement it won't be able to use? It can't even call the solib's i= nit constructors! Which of course makes me question the intended stability of your "small and smart" patches. There are plenty of ways to crash an application, let's not= add more, shall we? ;) --=20 You are receiving this mail because: You are on the CC list for the bug.=