From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501c.mail.yandex.net (forward501c.mail.yandex.net [178.154.239.209]) by sourceware.org (Postfix) with ESMTPS id B26F03858D1E for ; Tue, 14 Feb 2023 13:13:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B26F03858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yandex.ru Received: from sas2-ef0d127adaec.qloud-c.yandex.net (sas2-ef0d127adaec.qloud-c.yandex.net [IPv6:2a02:6b8:c14:6d1f:0:640:ef0d:127a]) by forward501c.mail.yandex.net (Yandex) with ESMTP id AEEC25F234; Tue, 14 Feb 2023 16:13:19 +0300 (MSK) Received: by sas2-ef0d127adaec.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id IDj0F43YAmI1-eOdlX51X; Tue, 14 Feb 2023 16:13:19 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1676380399; bh=W5Bw8giLnqPup1xnhu9wJBKAZuzShpxnTcBsGnBYwnY=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=cSTP6klS6aHXtv+J3ZXKeIPAWrPpp0bqIFX93OkaNG6uCC8UG8fnalsXJY6xaZpPR 5updXQHZp5wdtqy19jabe7WnqgDGFYTJ7DDUZvFxPT7Ct/zmGmgqKag6UmYG0ATnJS fVAoIUVOD1qI/Vughd6QznByEH+fD7Wgq77daCsQ= Authentication-Results: sas2-ef0d127adaec.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <78f30396-af4d-bb5c-e4cc-1781f26353bc@yandex.ru> Date: Tue, 14 Feb 2023 18:13:17 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 2/2] dlfcn,elf: implement dlmem() function [BZ #11767] Content-Language: en-US To: Florian Weimer , Stas Sergeev via Libc-alpha References: <20230214084123.2056067-1-stsp2@yandex.ru> <20230214084123.2056067-3-stsp2@yandex.ru> <87mt5ga82l.fsf@oldenburg.str.redhat.com> From: stsp In-Reply-To: <87mt5ga82l.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 14.02.2023 14:51, Florian Weimer пишет: > * Stas Sergeev via Libc-alpha: > With the mandatory copy, I'm not sure if this is a substantial > improvement over the pedestrian implementation using memfd_create, > included below. In its current form: - portability perhaps. Not many glibc-supported   systems have memfd_create(), though I am not   sure if it is any better than shm_open() here. - one more mem copy (write() in your case) - the need to peek into /proc just to get the   path for dlopen(). Again, with shm_open()   its probably simpler as it has an explicit mount   point at least. But considering the planned extensions, dlmem() offers the best potential than its alternatives. I want add a possibility for LD_AUDIT to provide an fd to dlmem(), from which it will mmap(). Currently it does anonymous mmap(), but this is only the first step. I want to provide it with the fd from shm_open() to have an ability to duplicate the solib in an address space. I have a 32bit VM, and the memory of the 32bit process is mapped to some window in 64bit address space. In order for this VM to work with solib, I need to relocate the solib to some low address in the first 4Gb. But the aforementioned memory window is above 4Gb. So my plan is: - in LD_AUDIT set the load address within low 4Gb - in LD_AUDIT provide an fd from shm_open() for dlmem() - mmap that fd into the VM memory window   in an upper space. I do not suppose such an extension is possible for any API that already has an fd. But adding an fd arg to dlmem() itself will likely be too confusing. So I decided to first create a minimal impl, and then extend it via LD_AUDIT multiple times. OTOH how do you propose to implement dlmem() directly on a user's buffer? If this is possible then maybe I can try that out. But the loader will need to move the sections around, overwriting the existing content. Or do you want the user to pre-load the sections to their vaddr's? In that case he will write the half of dlmem() himself. So my current understanding is that memcpy() is all or nothing. If we avoid memcpy(), then we avoid dlmem(). The dlmem() that you demonstrated, does even more memcopies than mine. > What's the debugger story with your dlmem variant? It looks like GDB > gets confused even with the memfd_create mapping, which really isn't > great. One can do add-symbol-file Unfortunately I can't figure out the right address... lm->l_addr from dlinfo() or dli_fbase from dladdr() do not suit, but they are close. Some offset is probably needed and I don't know what is it. :( Can try to figure that out if really needed.