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 DD8741F8C6 for ; Mon, 23 Aug 2021 13:52:08 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0188B3853C25 for ; Mon, 23 Aug 2021 13:52:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0188B3853C25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629726728; bh=zMrtXs+q8Z5ZomS+zSBdt1+UzxgS0QxX7zTIHfWrgQ4=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=tjS9kdQ/1x/Ip3H/AxKfcgz7kxhR6QIrugaxOcXRAUlMGSCf4iy5pxZctmpAr4tU6 jpmSlc3JOZfy95LvBWN/qahx0mS4/sk7g2LsgBNGE6zkmK0M5rOsNT1eiZjDgHZKDl UBd53xPhva98Q2PkXwpiO8qxNzy0twTMmAlJEggQ= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id F3CCC3857432 for ; Mon, 23 Aug 2021 13:49:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F3CCC3857432 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-155-eJ_kUkAZP9mNuU_QwxLeuA-1; Mon, 23 Aug 2021 09:49:43 -0400 X-MC-Unique: eJ_kUkAZP9mNuU_QwxLeuA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A5CDA101C8A0; Mon, 23 Aug 2021 13:49:41 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BC67160CC9; Mon, 23 Aug 2021 13:49:39 +0000 (UTC) To: "H.J. Lu" Subject: Re: [PATCH v6 1/1] : An API for tagged address References: <20210822124546.154232-1-hjl.tools@gmail.com> <20210822124546.154232-2-hjl.tools@gmail.com> <87fsv0se5s.fsf@oldenburg.str.redhat.com> Date: Mon, 23 Aug 2021 15:49:37 +0200 In-Reply-To: (H. J. Lu's message of "Mon, 23 Aug 2021 06:40:07 -0700") Message-ID: <874kbgp8y6.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.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: GNU C Library , Szabolcs Nagy , Joseph Myers , "Kirill A . Shutemov" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * 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). >> 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. >> 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? Thanks, Florian