From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 04B16385B51F; Mon, 6 Mar 2023 10:09:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 04B16385B51F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678097367; bh=wgUdudP7hDKootskhzlBImHDG2oHFH7la5ax9a+XCFE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fhrX8/0w8DPXlwIR1biHrHOH+C0M4b/neAdselEOGluFwtEd0J7H1lDhyq6s+yOTj dX8XsNX50XV27oklh371zZ5C5/ozzWztezk9slNke+4CWMeFh+2Pa+wVjxBpe+VXX3 SYQJ9vQ1To7Q5Kmwi8PWeinSjkvAPKTfWc4zthz8= 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: Mon, 06 Mar 2023 10:09:25 +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 #37 from Stas Sergeev --- (In reply to Jonathon Anderson from comment #36) > (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 importa= nt > > > callback for registering callbacks in runtime libraries before transf= erring > > > control back to the application. Is there a way to indicate to the au= ditor > > > that it's "missed the boat" so auditors that need this timing can rec= over > > > 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 > see la_dynload which indicates when an auditor is dynamically loaded, but Well, v9 only addresses this: "Is there a way to indicate to the auditor that it's \"missed the boat\"" by allowing you to tell anything you want to an auditor. > AFAICT there isn't a way to tell which la_objopen callbacks are "real" (n= ew > objects) or "fake" (objects already loaded). There is no such thing simply because the "late" objopen call is already an established practice in dl_main(). Which means its a bit out of the scope of this patch, but it doesn't mean I can't add such a thing. For example I can add la_objopen_late(). But let's see if it is actually needed. For example can't you use the fact that la_objsearch() and/or la_activity(LA_ACT_ADD) wasn't called before la_objopen()? > 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 > their constructors based on dependencies between objects and nothing else. Yes, so you need to add the "primary" ctor to the main object (not to any solib of it) and from that load the audit module, no? > 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. Exactly. > I assume there's a Very Good Reason (TM) the ancient code can't be compil= ed > 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. 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. Also the ability to work on host in 64bit mode provides performance and other benefits. 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. > I'm not confident this description is right based on your comments later.= .. But actually your description is very relevant! > And the call args can contain pointers, thus the need to ensure the point= ers > 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) ensu= re > pointers to data segments will work. Indeed! > What do you do about pointers to stack variables? 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. > That... makes absolutely no sense. In that arrangement the loaded solib w= ill > be useless outside the VM, the relocations are wrong for the 64-bit addre= ss > space. 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. And let me assert its very small for such a powerful functionality, because all it does is to pass the backing-store fd to dlmem. With that fd you can do whatever you want. So no lots of new and convoluted APIs, whereas the solved task is quite big. For the price of just 1 small dlmem() call! > 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? 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 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 smart" > solution is a tractable goal. After all, we're talking about multiple > architectures in a single process image. :P 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. No matter what arch problems does this solve, its simple by itself and only adds 1 API func that people requested many times. I am sure next time you'll deal with dozens of APIs to solve only some small part of the same problem. :) My impl is exceptionally minimalistic, I am quite confident in that. > Mind providing a couple good sources for what you're referring to here? Will do in an hour or so. Give me some time to collect the links for you. --=20 You are receiving this mail because: You are on the CC list for the bug.=