From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 64F5D385802F; Mon, 13 Mar 2023 10:46:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64F5D385802F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678704415; bh=75oQ1OWXPYTLKsMFFCj9dlR/kCUWmU8tain+LVsP+pw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TeWnC1reJXzRrcN49FaZ0FfHUiR0a0QsyhSQhpoy55/v7SpdHfUyo5QgvmS+JcXvF nS7nqhs/MXTdkdendduphXi5Z6cxoLZiFqfKwl7ukt8DgPQtErUOY8eNar5jJzyIQs lbyX1Gu2HguXpuvOnLH3s309NjtY441FVOoX19HM= 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, 13 Mar 2023 10:46:54 +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 #45 from Stas Sergeev --- (In reply to Jonathon Anderson from comment #43) > 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? Indeed, that's the case. I wouldn't go into such a long and deep hoops (where glibc is by far not the only obstacle) to just compile things for 32bits. :) > > 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 e= ven > mapped. The initial stack of what? Of an executable - indeed. But not of the lib I run through dlmem(). I call its entry manually, after setting up the things (including stack). > Do you switch stacks in your shim library, after the VM memory > region is decided upon? Indeed. These things are done through makecontext(). > While on the topic (and mostly out of curiosity), what do you do when the > 64-bit code allocates more than 4GB of memory? This 64bit code is compiled from ancient sources, that shouldn't do that. So if it does, it will just get the malloc() failure. I run it with the custom libc - that allows me to control everything. No direct host calls are allowed. I am using RTLD_DEEPBIND and a new NS. Well, "using" is a too loud statement, as before things settled to glibc, I have only a rough tests and prototypes. But I tried similar concepts in the past, so I am pretty sure the scheme is functional. > > by doing 2 mappings of the same lib.=20 > ...If all you wanted was to mmap the solib to another address, you can > already do that using mmap and /proc/self/map_files/. Maybe dl_iterate_ph= dr. That can only work for loadable sections, I believe. .bss cannot be shared that way, and likely much more. > 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. But as I already mentioned, I do 2 identical mappings. One at reloc address, one at mmap address. So even though reloc_address!=3Dmmap_address, things do work, because because the one at mmap_address is only used for data accesses, and the one at reloc_address is used for everything (like code calls). > 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 > solib useless there. Not quite useless: data access by 32bit code is done there. Everything else is done at another address. So every mapping does only what it can. > I see no way for an solib to function in both "worlds." AFAICT the best y= ou > can do is "manually" (i.e. not via data symbols) access the data segment > from the "other world," functions simply won't work. Indeed! Functions will work when shim calls them (via the right mapping). "not via data symbols" is not a problem, because when the call is in the VMs "world", it has the ready to use pointers inside the call arguments, and nothing else. Only these pointers should work there. These pointers lead to a reloc address, but because the VM window is itself shifted, they need to go through the alias at mmap_address to reach their destination at reloc_address. mmap_address=3Dreloc_address+VM_window_start > You can specify the backing-store fd with classic dlopen and /proc/self/f= d/. > That's a very simple solution, and requires no changes to Glibc. Not sure I understand that part. dlopen() uses source fd to map it to reloc_address, but the data sections are just anonymously mapped. So I am lost, what does /proc/self/fd do with all that? > Glibc patches. As noted above, I'm not yet confident your use case would > work even if you could specify the reloc base address. >=20 > I don't see any reason to support the (reloc base address !=3D mmap addre= ss) > case. It's utter nonsense. If alone - yes. But when you have multiple mappings, one of which is still at reloc_address, then things magically start to work again. Probably you still haven't realized the whole power of la_premap_dlmem(). Please note that la_premap_dlmem() is not the same as la_premap(). These are different extensions, but when they play together, that can do Real Things (TM). > AFAICT these discussions are all solved by memfd_create. Almost all of the > complaints revolve around the memory vs. disk performance difference, I am getting a bit nervous already when people mention memfd_create(). :) In what way is it any better than shm_open(), that I used in my la_premap_dlmem() example? Yes, I could also use memfd_create() with la_premap_dlmem(), but I prefer shm_open(). Why people think that memfd_create() is the thing, is unclear to me. :) But it fits my design very well, as does shm_open(). > memfd_create is a very easy way to get a memory-backed file on modern Lin= ux > boxes. ... and provide it to la_premap_dlmem(). But I'll use shm_open! :) > > Mapping to specific address was requested: > > https://stackoverflow.com/questions/62064806/is-there-a-way-to-specify-= the- > > 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 would= n't > consider this worth much attention. Well, I am not saying these examples deserve much of an attention. But I used them to bring up an API that at least is requested multiple times, and layer the rest on top. The warning here is the next time you'll deal with much more alien and complicated API that won't solve the entire task even. So why not to use mine, its was requested multiple times, its written, it will be proven (within this thread) to solve the stated task, and very unlikely some hack can be proposed as an alternative. --=20 You are receiving this mail because: You are on the CC list for the bug.=