From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id B556C3858417 for ; Mon, 23 Aug 2021 14:16:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B556C3858417 Received: by mail-pf1-x434.google.com with SMTP id w68so15477757pfd.0 for ; Mon, 23 Aug 2021 07:16:12 -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=cl+3gRNaZGnLp5kYPf+Jv4DrvAp1xlCOB3ZSeoL3JiU=; b=RZRcVkxBKAw9EJmeCrNEFUcfuyWt+xkDjvmVrwYfA/7QOU5o1xPfBdyICha5gM2N4C /2sZkp6ZSxzZYLOmFWC3wd71QUMxPTkfa4pQIm+LYww9wohBedLzIqPadXlAty0r9RBy VUlvYp8Vfi2sW8CBCK0WesKba4sm5QiiXenImZCVpNMBJHvKN2tUAFU2s3N+isSaSbNA lO5BrwX/MO2Nmw2Gm+VAtgXuhXsvcVjO+5vLrMqwDdIs6guYzqwgEMQZVIxC9UYZ3gNb G5hrwHAUccRbanxdhDgffWnsn02zU3cirbEgYOfj+1z+Arqd2PzmyQOUrkmoMZBpKZly mUJA== X-Gm-Message-State: AOAM531yVr5VQX+YlAFhYRqzFuatd+Aoxa20SgApsp2IHUFq+7Nmkswk 0vPXdKqNAc+9+b/YtMBhCY0gN+bq4Yt0m+k+hGg= X-Google-Smtp-Source: ABdhPJxkS4yxESKjpGDuu1RAbrlE9saDNd+GNy6UNjWwRX/7BVh1wrI+m9Qk22vdAXL8waYVWaJtzXU8L0zYhKxZe9Q= X-Received: by 2002:a62:7e41:0:b029:3e0:9c3f:ab50 with SMTP id z62-20020a627e410000b02903e09c3fab50mr33645414pfc.57.1629728171748; Mon, 23 Aug 2021 07:16:11 -0700 (PDT) MIME-Version: 1.0 References: <20210822124546.154232-1-hjl.tools@gmail.com> <20210822124546.154232-2-hjl.tools@gmail.com> <87fsv0se5s.fsf@oldenburg.str.redhat.com> <874kbgp8y6.fsf@oldenburg.str.redhat.com> In-Reply-To: <874kbgp8y6.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Mon, 23 Aug 2021 07:15:35 -0700 Message-ID: Subject: Re: [PATCH v6 1/1] : An API for tagged address To: Florian Weimer Cc: GNU C Library , Joseph Myers , "Kirill A . Shutemov" , Szabolcs Nagy , Adhemerval Zanella , Sunil K Pandey Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3024.5 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 23 Aug 2021 14:16:14 -0000 On Mon, Aug 23, 2021 at 6:49 AM Florian Weimer wrote: > > * H. J. Lu: > > > On Mon, Aug 23, 2021 at 2:28 AM Florian Weimer wrote: > >> > >> * H. J. Lu: > >> > >> > By default, the number of the address bits used in address translation > >> > is the number of address bits. But it can be changed by ARM Top-byte > >> > Ignore (TBI) or Intel Linear Address Masking (LAM). > >> > >> I think the fundamental concern is that we don't really know today how > >> this API would be used. Szabolcs has said that Arm doesn't need this > >> API for HWSAN. TBI has already other (incompatible) users, I think. > >> (Although OpenJDK's ZGC garbage collector has moved off it.) > >> > >> My concern is that this interface essentialyl sets in stone a certain > >> programming model for LAM, and we really don't know today if that's the > >> right approach. > > > > My current API has only set_translated_address_mask to enable LAM. > > It doesn't specify/know how LAM is used. I don't see there is an issue > > here. > > It's still unclear who owns the tag bits, and if the behavior is > expected to be like the kernel (e.g., glibc masks all tag bits in > dladdr so that they are ignored not just at the hardware level). We don't have to decide now. We will learn more with HWASAN. With set_translated_address_mask, glibc can control/change how tag bits should be used. With kernel API, glibc is out of the picture. > >> I also expect that HWSAN needs to poke at glibc internals, like the > >> other sanitizers, so I don't see why calling a kernel API behind glibc's > >> back would be problematic. > > > > The LAM enabled glibc should support all LAM usages. memmove > > needs to know the LAM bits to work properly. > > Only if it is permitted to change the tag on subobjects, which I don't > think is the case. Otherwise overlaps necessarily have the same tag, > and the existing pointer comparison works as expected. It is not about overlap. I am concerned about copy direction, like if (dest > src), will it be a problem? > >> As a side effect of the libpthread merge, we freed DF_1_INITFIRST for > >> other uses, so you should be able to work around initialization ordering > >> issues, too. > > > > The issue here is that LAM should only be enabled ONCE before main > > and thread creation. Neither DF_1_INITFIRST nor kernel API can properly > > enforce it. > > How does AArch64 solve this? Different kernel API? I don't think that AArch64 has addressed this issue at all. -- H.J.