From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501b.mail.yandex.net (forward501b.mail.yandex.net [IPv6:2a02:6b8:c02:900:1:45:d181:d501]) by sourceware.org (Postfix) with ESMTPS id 86FD13858D1E for ; Mon, 13 Feb 2023 16:36:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 86FD13858D1E 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 sas8-838e1e461505.qloud-c.yandex.net (sas8-838e1e461505.qloud-c.yandex.net [IPv6:2a02:6b8:c1b:28d:0:640:838e:1e46]) by forward501b.mail.yandex.net (Yandex) with ESMTP id E1D3A5ED0D; Mon, 13 Feb 2023 19:36:35 +0300 (MSK) Received: by sas8-838e1e461505.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id YaluTl1YseA1-VKFLDVFH; Mon, 13 Feb 2023 19:36:35 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1676306195; bh=C6acTk5TWPFj8xPlj1MQ/mMu1E6zQ9qqLXeLpZ0YayE=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=S5am17LC//+Njrck7/d3M8VltN6k4KtQ5eeQ4cXu66lvQ1pQ6S388khOibVvg3eaA zW0KDQw3V8Gi1ET1GY4rpMaT1IhlN02CuvCArBmgGHLHa1kkvd0IYnmwnWgZ6Pm/Pz csNrHnAeLsHLys8/YnbBVr8ozMK8Brnq9990VXjk= Authentication-Results: sas8-838e1e461505.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5635996a-a645-952f-9152-9a5ec1b940d3@yandex.ru> Date: Mon, 13 Feb 2023 21:36:34 +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: <20230213132307.528976-1-stsp2@yandex.ru> <20230213132307.528976-3-stsp2@yandex.ru> <87y1p1d6go.fsf@oldenburg.str.redhat.com> From: stsp In-Reply-To: <87y1p1d6go.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 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: 13.02.2023 18:45, Florian Weimer пишет: > * Stas Sergeev via Libc-alpha: > > On the Google branches, there is somewhat similar functionality, in the > form of dlopen_with_offset. I've seen its mentioning here: https://sourceware.org/bugzilla/show_bug.cgi?id=11767 But the attachment that is supposed to be that patch, is "attachment-3251-0.html (112 bytes, text/html)", and if you click on it, you'll see something completely silly. So I thought that patch is a vaporware. And in any case, I don't have an fd at all. Maybe if they implemented dlopen_fstream(), then I could use it with fopencookie. But overall I need dlmem() w/o any fd. > Their approach avoids some ambiguity > inherent to to the dlmem interface, mostly around whose responsibility > is it to set up the page protections. You probably mean the ambiguity of _their_ dlmem() interface. They discussed it entirely differently: they wanted dlmem() to work on a user's buffer. My approach is very simple: dlmem() does any mapping and protection, and memcpy() from the original buffer. Then user does munmap() of his buf. dlmem() to user's buffer will be added later. I am going to add it via an LD_AUDIT extension that tells you the size and gets back the address where you want it to mmap the solib. So while I want to cover all their ideas, the implementation is very simple and no ambiguity should arise from it. > Your patch seems to allow the creation of fully unnamed link maps > (especially if the shared object being loaded does not come with > DT_SONAME). I think we need to discuss the consequences of that. This > feature could be independently useful to some applications, to the > extent that they would use dlmem just for that purposes (even for files > that are stored on disk). Yes, I actually thought of a possibility to set a name... Although this can be done later, by someone who needs it. Probably that will require dlmem2() with one more argument. > The test case could be extended to cover some failure cases, like a > purposefully misaligned buffer containing a valid ELF object. For my impl its not a failure case, simply because of memcpy(). > Or the > interaction with auditing. I was planning that for the next patch-set where I will be covering the user's address. But I'll see what can be added to current one.