From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 345031F8C6 for ; Mon, 23 Aug 2021 14:16:34 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1F99C3857C60 for ; Mon, 23 Aug 2021 14:16:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F99C3857C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629728193; bh=cl+3gRNaZGnLp5kYPf+Jv4DrvAp1xlCOB3ZSeoL3JiU=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=oQyRk0NX+Z99MlgYdEGslXN9OZGvqBpml+XW4Goj/VgP9NGe6omSBB5Jt33A4DSpo ApdwHWyOiVrUfOYA1ET9SWVl+plBUYIuA+e7NCM4Y86GD9l+jRE2+Rr/QKib5/LuPr /O+BpoQN6tWdC+NmLW7HE0G35ZwnVSJA+V3PdWj4= 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> 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 Content-Type: text/plain; charset="UTF-8" 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: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: GNU C Library , Szabolcs Nagy , Joseph Myers , "Kirill A . Shutemov" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" 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.