From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 321733858C54; Fri, 3 Mar 2023 06:20:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 321733858C54 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677824442; bh=2Lw3/peS7lOkbQO5oFD7YHSGpAzibxPF3FPVUBoRaEk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wpjymKwX1wPUomSnPH6Fop4BH/xJoI1jfdM/XC8Ni4UiNaw4rLTBytkOCL20nb1Q8 XEi39y7HuI4gszOpkCPzYdXRhwslShcCqSUgxr0Lv8I0p+yrYlSZTeD6wrKjJYGJZ9 UQO17//WIWQnA1RrHFVh84oQG53FK5uNiEoTKXQ8= From: "janderson at rice dot edu" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30127] [rfe]: enable ld audit at run-time Date: Fri, 03 Mar 2023 06:20:41 +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 #33 from Jonathon Anderson --- (In reply to Stas Sergeev from comment #32) > (In reply to Jonathon Anderson from comment #31) > > I can't say the current solutions are appealing. You've made it very > > difficult for a dynamically-loaded auditor to accomplish any auditor-li= ke >=20 > Posted v7 which just calls la_objopen() > for pre-existing libs, similar to dl_main(). 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 transferring 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? >=20 > > You mentioned in another ticket > > (https://sourceware.org/bugzilla/show_bug.cgi?id=3D30007#c2) that the w= hole > > point of this is to access data objects in the solib. Do you write this > > solib? >=20 > I write a shim that should load (via dlmem()) other > libs, built from some 30 years old sources (that neither > me nor anyone else writes today), and allows them to work > on a current system. I.e. this is a compatibility layer. > Compatibility layer, unfortunately, can't require changing > the legacy code. What you propose, will require mostly a > full rewrites, eg I have no idea how would the one identify > all pointers to all vars and change all such vars to a heap > objects... Why would you have to lift the variables in the legacy code? Those are alre= ady "inside" the VM, right? What it sounds like you're trying to do is pass a pointer to the data segme= nt of a 64-bit library "outside" the VM to the 32-bit legacy code running "ins= ide" the VM. Which it will then dereference to access or alter some variable sha= red "across the VM gap." Does this match your use case? 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 restrictive address space and reference from "outside." In this case Glibc doesn't even= get involved. The only reason you would require dlmem() or la_premap is if you didn't con= trol the 64-bit library who's data segment needs to be shared "across the gap." = Is this the case? >=20 > > Could you override mmap itself for the files you want mapped in the rig= ht > > locations? >=20 > But it won't be relocated to that address. The result of the first call to mmap() for an solib decides the base address for the solib, which is the address all relocations are relative to. So it should relocate to the right address if your mmap wrapper is sane. See _dl_map_segments (esp. lines 85-95 and 106) and _dl_map_segment. There's a performance penalty to syscall wrapping (and it's arch-specific a= nd ugly), but AFAICT it should work just fine for this case. >=20 > > You mentioned DT_AUDIT wouldn't work, so I presume the executable is ou= t of > > your control, e.g. you're extending a VM with an solib plugin? If so, d= o you > > not have the access to set LD_AUDIT in the environment before launching= the > > executable? You can always make your auditor "no-op" except when needed. >=20 > This is possible but a quite clumsy solution IMO. > And of course it would still need all other patches > (dlmem etc) except this one. So I'd rather concentrate > on making dlload_audit_module() suitable for your needs. This solution matches well with the (few) use cases auditors have been test= ed in so far. If you want something that *works* (reliably) for this rather specific use case, a little clumsiness is the least of your worries IMHO. --=20 You are receiving this mail because: You are on the CC list for the bug.=