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.133.124]) by sourceware.org (Postfix) with ESMTP id 0E968384A02B for ; Fri, 7 May 2021 08:24:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0E968384A02B Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-316-RzR5_sa1PtSClbQu7j4gXA-1; Fri, 07 May 2021 04:24:28 -0400 X-MC-Unique: RzR5_sa1PtSClbQu7j4gXA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9D581800D62 for ; Fri, 7 May 2021 08:24:27 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-137.ams2.redhat.com [10.36.112.137]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 139DA687C7 for ; Fri, 7 May 2021 08:24:26 +0000 (UTC) From: Florian Weimer To: libc-alpha@sourceware.org Subject: Programming model for tagged addresses Date: Fri, 07 May 2021 10:24:46 +0200 Message-ID: <874kffeysx.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 08:24:33 -0000 This is related to this bug: memmove doesn't work with tagged address The bug is about detecting memory region overlap in the presence of tagged addresses. This problem exists also with address tagging emulation using alias mappings. If tags are fixed at allocation, I do not think these comparisons are a problem. The argument goes like this: Backwards vs forwards copy only matters in case of overlap. All pointers within the same top-level object have the same tag, so the existing comparisons are fine. Overlapping memmove between different top-level objects cannot happen because top-level objects do not overlap. So you have to copy multiple objects to get an overlap, but that copies data between the objects as well, which is necessarily undefined. Things change when applications are expected to flip tag bits as they see fit, including for pointers to subjects. This leads to the question whether it's valid to pass such tag-altered pointers to glibc functions and system calls. Many objects have significant addresses (mutex and other synchronization objects, stdio streams), so the answer to that isn't immediately obvious. The next question is tag bits coming from glibc and the kernel are always zero initially. For example, for malloc, we currently use two bits in the heap to classify chunks (main arena, non-main arena, mmap). These bits do not change after allocation, so it is tempting to put them into the pointer itself. But this means that some of the tag bits are lost for application use. Thanks, Florian