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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 22BC61F8C6 for ; Mon, 6 Sep 2021 08:56:34 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 08C34384B808 for ; Mon, 6 Sep 2021 08:56:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08C34384B808 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1630918593; bh=TRDnP9ofVV34LXGmuWJkbF20CyUpFOAb6E1e9Bon7T8=; 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=gLRuL7qRdnGSfhfbldRmRWeOKct7jJq0B2VVrpS8fQJzKOwTQ4xOzIee9iHZLTM21 o7AQLNPCFSZFla8WEh2y7BmdwTm+has5cHnXypT68oBnITfpdozLfntntxyr1QvO3e L4ljv7yN2Htfv2V8xh4+uNIdjenGKZUpZyLRyftU= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 55F0B3839401 for ; Mon, 6 Sep 2021 08:52:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 55F0B3839401 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-474-4EzJhkv6NySHUW0SqORNJQ-1; Mon, 06 Sep 2021 04:52:26 -0400 X-MC-Unique: 4EzJhkv6NySHUW0SqORNJQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BCD5C1854E2D; Mon, 6 Sep 2021 08:52:24 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.140]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0C9DA6F7EB; Mon, 6 Sep 2021 08:52:21 +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> <874kbgp8y6.fsf@oldenburg.str.redhat.com> <20210903091231.GC21740@arm.com> Date: Mon, 06 Sep 2021 10:52:19 +0200 In-Reply-To: (H. J. Lu's message of "Fri, 3 Sep 2021 06:58:48 -0700") Message-ID: <87k0ju13y4.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.11 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: Szabolcs Nagy , GNU C Library , "Kirill A . Shutemov" , Joseph Myers Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * H. J. Lu: > On Fri, Sep 3, 2021 at 2:12 AM Szabolcs Nagy wrote: >> >> The 08/23/2021 07:15, H.J. Lu via Libc-alpha wrote: >> > 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: >> > > >> 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. >> >> i expect the hwasan runtime to have an initializer that >> ensures that it runs once, early (e.g. the shadow map >> has to be set up very early too: before any instrumented >> user code may run) > > There is nothing in glibc to enforce it. LAM can be used by > HWASAN or others, including glibc itself. We need to a way > to control it so that > > 1. LAM can be enabled properly. For example, if LAM has > been enabled and used by HWASAN, it can no longer be > used by glibc itself. > 2. LAM can't be disabled arbitrarily. We can't disable LAM > or change LAM_U57 to LAM_U48 when LAM is in use. > > Otherwise, we may get crashes, surprises or security issues > when LAM is enabled/disabled at random places. But these things are already happening with the software-based Address Sanitizer. I doubt these long-standing issues will be fixed by LAM because they are not a hardware limitation, but the result of a lack of coordination between projects. Setting up LAM is just one more issue in a long list of things that can go wrong. And if LAM does not have an ABI impact, it can be backported, which would be nice. Note that in glibc 2.34, we freed up DF_1_INITFIRST, so you could use that to set up things really early. Thanks, Florian