From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id E9AD8383543A for ; Fri, 7 May 2021 11:49:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E9AD8383543A Received: by mail-ot1-x329.google.com with SMTP id c8-20020a9d78480000b0290289e9d1b7bcso7664445otm.4 for ; Fri, 07 May 2021 04:49:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QSnAv+Y1/5M8Kqi72RfcrggN71UcXeyIEn86z7R3RQU=; b=RMXCrfvSJYD+W3ZqgVF/sujN7QNU96Mnrze+FCp780GbGUTdFtwl6cpWFn/k1jd5IW dRYioMxRCc/nUqBq6CZX23eq+n+mLRSSEbOlr2tLXnpAYbgleuEB/hsCO1lrwuK3nXgF pBygQWNiByoX8C1vFZomF0l2x/QMMeGjNxOizrKPcmnjwCyEtYGiRHBMY5jOH9aapczX 4O5w6En2yM3ZNVu/5J/8PKXUelLOwuDXjauittBa8f386JIjrxHiLKaPVZa39lLFoZre FNNEDSjVHPdzvt8siLj4Eo5SSMFpiNwBYuR71cZOg7EpfQ8xZ/78TeZSWFjjF5JGWeQF vTlg== X-Gm-Message-State: AOAM532f2ds2FS5lwRFtAOBb3WVirmhyrYSGgYoiMW4J28RJwoGJdFV7 ibc8dBPeEXunhZvGQTpMaJh62tLqHjI5MhMV1NdvzMKmfBU= X-Google-Smtp-Source: ABdhPJyJkMl32teBnnaw6YbnKqvM/QJ/eHM6YYzKQWn902ZlfBugoyv7GX1VxKwt3GIdFh0bY3J4TdB1MexS3z3Cmm8= X-Received: by 2002:a05:6830:15d2:: with SMTP id j18mr7872467otr.89.1620388146436; Fri, 07 May 2021 04:49:06 -0700 (PDT) MIME-Version: 1.0 References: <874kffeysx.fsf@oldenburg.str.redhat.com> In-Reply-To: <874kffeysx.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Fri, 7 May 2021 04:48:30 -0700 Message-ID: Subject: Re: Programming model for tagged addresses To: Florian Weimer Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3028.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 11:49:08 -0000 On Fri, May 7, 2021 at 2:33 AM Florian Weimer via Libc-alpha wrote: > > 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. It should be valid. Otherwise, we don't need TBI nor LAM. Glibc just needs to be aware of the valid address bits used for address translation and handle it properly. BTW, kernel can handle tagged addresses today. > 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. Applications may put tags in tagged bits on pointers returned by malloc or mmap. Glibc should always clear the tag on pointers when operating on such pointers if needed. -- H.J.