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_HI,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 507BE1F8C6 for ; Mon, 6 Sep 2021 13:35:17 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EC6063857027 for ; Mon, 6 Sep 2021 13:35:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EC6063857027 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1630935316; bh=JPZLdJMHJ+rIWkSpZrLRS6O/SG+VxBATLAw70FdUclg=; 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=otYIprnbA2mwScveqjyyWICiB8P96r3srSwqKnAJWLV5+FE5ZndjZOGbqR00HwYtV 9VE9YgZb/PQ9bRqHNa9winTQ3Ky+mYGft7/23B1VWspN8qJlkN3JB4ca7mHHNSDWm3 YMRwbBrGQlgXEJF6YaeSzPFydG5Zka8bL/vehhng= 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 BB8583858414 for ; Mon, 6 Sep 2021 13:34:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB8583858414 Received: by mail-pl1-x636.google.com with SMTP id m17so3953208plc.6 for ; Mon, 06 Sep 2021 06:34:55 -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=JPZLdJMHJ+rIWkSpZrLRS6O/SG+VxBATLAw70FdUclg=; b=GOtc0I7AO+3JSNUrOypC0S3jUBMNJiOe5+pwH+ncIEZrzc6qsC6QNLcJVRe+5kZUL7 vq/Oj6tsxNDf1A3C1p1FZCO1o7yHRUtt0vXlhYp7FdoOUwPj4sGO96JcEkCyCIKh+G6p BiPT1YIrK09vsy+bCB4PU31rJ5fJ/s2J+M1W9nbIE0/lvVHwJOcjd5sdaYwtaP9sFjht t/pJ/viRh3EMAbKFmrYLMHQbFcte95IasWjWoeNKZ+LXIC0RsxEUuP2iuhP4mT+v1XFU Ss2zHB6FWQWrSaXohzuJxbdwTz+77CrjmqrA+FKJk8r5yUXA2Uif6TZV22IgX9GrJHri HmEg== X-Gm-Message-State: AOAM531kpOUpjp5yA5tnh6bWI4HRnrmttc/1+IR79PohzRfc89F5Yl0A jKU5pQmqphXCHqScQxwl7rVRtvnmJZxIlA1P38Y= X-Google-Smtp-Source: ABdhPJxjaL3WjBzE9aiaQOZW9/+Mw3MuAZZoBKS6MuShoQngEtJkIoo6+1sQpChxNf043J+Bakhg5lk33/OLtlUsru8= X-Received: by 2002:a17:902:c643:b0:138:b603:f93e with SMTP id s3-20020a170902c64300b00138b603f93emr10805945pls.66.1630935293874; Mon, 06 Sep 2021 06:34:53 -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> <87k0ju13y4.fsf@oldenburg.str.redhat.com> In-Reply-To: <87k0ju13y4.fsf@oldenburg.str.redhat.com> Date: Mon, 6 Sep 2021 06:34:18 -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: Szabolcs Nagy , GNU C Library , "Kirill A . Shutemov" , Joseph Myers Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Mon, Sep 6, 2021 at 1:52 AM Florian Weimer wrote: > > * 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. But I don't think we should add LAM to the list of the long-standing issues. Without an API, we can never safely use LAM in glibc at all. > 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. I backported it to glibc 2.33: [hjl@gnu-cfl-2 tmp]$ ar -t /lib64/libc_nonshared.a elf-init.oS atexit.oS at_quick_exit.oS pthread_atfork.oS set-translated-address-mask.oS stack_chk_fail_local.oS [hjl@gnu-cfl-2 tmp]$ ar -x /lib64/libc_nonshared.a tagged-address.oS set-translated-address-mask.oS [hjl@gnu-cfl-2 tmp]$ nm set-translated-address-mask.oS U errno U _GLOBAL_OFFSET_TABLE_ U _rtld_global 0000000000000000 T set_translated_address_mask U __stack_chk_fail_local [hjl@gnu-cfl-2 tmp] At least, the same source can compile with glibc 2.33 and the binary linked against glibc 2.33 will run with newer glibc. > Note that in glibc 2.34, we freed up DF_1_INITFIRST, so you could use > that to set up things really early. What do you have in mind for LAM with DF_1_INITFIRST? How can it address the LAM issues I have? BTW, DF_1_INITFIRST doesn't help backport. > > Thanks, > Florian > Thanks. -- H.J.