From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 99D413858436 for ; Mon, 13 Feb 2023 13:45:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 99D413858436 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676295946; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Y+2vwgc5p3O6MfvBeUJjyItQGyXdmc05Yg/Jiw0f+jg=; b=GXk9Ek86bG2bYBISS+pa80fhmpQh06P+qwWOvO1hBxS40frXogc+EXawxw1wZdWEw6Q33V 1Q79Er/tRSuSiTvS0sdpvaywxQMlsVvtHgYaoYskOn1iv3h4gAhAHGPoL3fErBnVXFZQ4P Wqacf36j9RyUPOxR3LN/2wqFsR0rWAk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-101-vOyJ7hpcPVeCasqRSGqpWA-1; Mon, 13 Feb 2023 08:45:45 -0500 X-MC-Unique: vOyJ7hpcPVeCasqRSGqpWA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C6938811E6E; Mon, 13 Feb 2023 13:45:44 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54F90400D927; Mon, 13 Feb 2023 13:45:44 +0000 (UTC) From: Florian Weimer To: Stas Sergeev via Libc-alpha Cc: Stas Sergeev Subject: Re: [PATCH 2/2] dlfcn,elf: implement dlmem() function [BZ #11767] References: <20230213132307.528976-1-stsp2@yandex.ru> <20230213132307.528976-3-stsp2@yandex.ru> Date: Mon, 13 Feb 2023 14:45:43 +0100 In-Reply-To: <20230213132307.528976-3-stsp2@yandex.ru> (Stas Sergeev via Libc-alpha's message of "Mon, 13 Feb 2023 18:23:07 +0500") Message-ID: <87y1p1d6go.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: * Stas Sergeev via Libc-alpha: > This patch adds the following function: > void *dlmem(const char *buffer, size_t size, int flags); > > It is the same as dlopen() but allows to dynamic-link solibs from > the memory buffer, rather than from a file as dlopen() does. > > "buffer" arg is the pointer to the solib image in memory. > "size" is the solib image size. Must be smaller-or-equal to the > actual buffer size. > "flags" is the same flags argument used in dlopen(). > > The idea behind the implementation is very simple: where the > dlopen() would mmap() the file, dlmem() does anonymous > mmap()+memcpy(). > Unfortunately the glibc code was too bound to the file reads, > so the patch looks bigger than it should. Some refactorings > were needed to avoid big copy/pasts and code duplications. > In particular, _dl_map_object_from_fd() was split and now calls > 2 functions that are also called from __dl_map_object_from_mem(). > The same treatment was applied to open_verify() - the part that > can be shared, was split into do_open_verify(). > > This patch adds a test-case named tst-dlmem. > The test-suite was run on x86_64/64 and showed no regressions. On the Google branches, there is somewhat similar functionality, in the form of dlopen_with_offset. Their approach avoids some ambiguity inherent to to the dlmem interface, mostly around whose responsibility is it to set up the page protections. 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). The test case could be extended to cover some failure cases, like a purposefully misaligned buffer containing a valid ELF object. Or the interaction with auditing. Thanks, Florian