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 D6A491F8C6 for ; Fri, 3 Sep 2021 14:00:23 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0328C384840E for ; Fri, 3 Sep 2021 14:00:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0328C384840E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1630677622; bh=WVKMX1yzInhaOqzB3P/aOKg2ADFSlT0emwiL9LnNlQE=; 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=lcgtmJ1Tgph5wc7Pqut1I1v7eBav7/y00RPNeQ91HmUA1dNZR4hzTH06O5fqbrL+m WXOWZCdsqRiMPbqYh6YbudOwzEq7uvVrpGJ0daKsBu/jcpQnO+tzofUc+e6vTyTOac vOMrZUmSeRdrQ9+BcR5XrdH+Xx4TYncJQkTDHNvE= Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 41464384841A for ; Fri, 3 Sep 2021 13:59:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 41464384841A Received: by mail-pl1-x636.google.com with SMTP id j2so3368071pll.1 for ; Fri, 03 Sep 2021 06:59:25 -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=WVKMX1yzInhaOqzB3P/aOKg2ADFSlT0emwiL9LnNlQE=; b=dNIzGSXA7NsRWadA13s3R6Wd67KFAb016gngZuLw2wo7MVcsiT9buOAZ/Pet7cpKQB syQotw73TUQpAtduIOshL3B0n63hDuhYqoiN8qFanuS5xuZyuBzcNRl9va9geUHE02Nd ifi/Hu1Dmo08j7BAzk3uGoRyA4pAg4PvZrJPguq2ZoU45vlKPaghefzpUidTQKb4yGmA ZwedoqnamYkGAiBTzuHbWzSOYI/b8hYpIalW0UkoMKo1xaTIBlJyaYNEydsB8I8x4/Fi fwRNlMJyOmKfv91KYxZhsTpN/I3Wckd83OgFCqYI1sIbYRcdoWEODi+X/qvanx6V5bcv OsiA== X-Gm-Message-State: AOAM533ZKgGwTulB7V15Y863tkTgERLfdfHzYrgUowt/MghS9kG4IBBd 0R+lC3jq5BA6O6vm443c08Gvm45mgwBmTJdwngs= X-Google-Smtp-Source: ABdhPJxpdQDjb3JQcs+HlBEtezipRVbE/w1L4t84/5ZiW02CF4qEgzSHwd5hlzMpywOn4gu7m/ru/LXRBXe0iXJUquE= X-Received: by 2002:a17:90a:598e:: with SMTP id l14mr9951447pji.28.1630677564378; Fri, 03 Sep 2021 06:59:24 -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> <20210903091231.GC21740@arm.com> In-Reply-To: <20210903091231.GC21740@arm.com> Date: Fri, 3 Sep 2021 06:58:48 -0700 Message-ID: Subject: Re: [PATCH v6 1/1] : An API for tagged address To: Szabolcs Nagy 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: Florian Weimer , GNU C Library , "Kirill A . Shutemov" , Joseph Myers Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" 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. > is there a reason the lam setup cannot use this mechanism? See above. -- H.J.