From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id A2A9D3858003 for ; Mon, 23 Aug 2021 13:40:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A2A9D3858003 Received: by mail-pj1-x1034.google.com with SMTP id 28-20020a17090a031cb0290178dcd8a4d1so23497pje.0 for ; Mon, 23 Aug 2021 06:40:43 -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=O8Q5S/mqsWV+PxLt5IZj5pk6+ZR65+wlONDmbvsCAvY=; b=WXcKSXbwPFBGSHBQkGZiiwomsi1ZNZ57/Rej4EBfUpSgSXv5ws5BfLb4vg6PhI7msb 6j29NefGdITa+GvQKet9YFvXKoR+3CnLVzEL5zJMBOwyerMQFG2HAwqXfP0oYpPrtBCn hUO+jupLxchrH8DjUxRY+qsPg+fna5rfwTRz51zpGhk1QS5YEPQONhwlEgu1COILh6bi JLxQz45Zs0J8TPMAPkoWt8DOIlc5ps/d4sGjfkewE2l+hKUuHB942x8sIcIsFC6oBqJ6 YNOGPkuBXZeGnYL7x/Boxt5sZReOcmrNM0hoLEU0VuvXA9BCUAfqM9FRXkvCbuH9JoCy JE8g== X-Gm-Message-State: AOAM532MPlOc8KqO86pOgF7KpPZ6jct51OENQHJIAkOdKpkZgus4mPz1 vfJNp7Q5QglBp9AJEopHhxMsXgIrW9OWrTkVtr0= X-Google-Smtp-Source: ABdhPJx9g92U4TeoP1wTO3Jv5J1Amvfur+o6udbg6GdyA+lkGvsX9afDNFq+Zgcv+sRmoipC9sVy/DHnkW5fgv08t8I= X-Received: by 2002:a17:90b:30d0:: with SMTP id hi16mr20491239pjb.154.1629726042739; Mon, 23 Aug 2021 06:40:42 -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> In-Reply-To: <87fsv0se5s.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Mon, 23 Aug 2021 06:40:07 -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.4 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 13:40:45 -0000 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. > 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. > 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. -- H.J.