From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by sourceware.org (Postfix) with ESMTPS id 16337386103F for ; Wed, 25 Nov 2020 16:40:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 16337386103F Received: by mail-qt1-x844.google.com with SMTP id 7so2043340qtp.1 for ; Wed, 25 Nov 2020 08:40:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8gX48PRLTQo+mXY6Fq9bfxLS3B40BOz/vWMIkM6dtoE=; b=hoGXLLKvSyv/9HQEUEkJyTldF+fjR2WHQeTvQcqi23JTU3beAQjfLVhxeYrvHOKz6Q 3p7bq1jo/xSsZ3ainfuIONw7ZTwDqhWJyLafnjryEeY3ZhTLHcR2ZEGkMGZXU2HehM50 UcvlVrBBUGKtDzbuzltrK5P9SPNjZArbQ9dawmJrws2DS4ggQFCLjb4JQ3k+x4DEDHfG mHP5fUTmdJLDoK8T3UdxGnh6kyD55JldbzNKHhI0xdrBlpglubaWrgTUlhG/INolL+kc DKfEVL5HJvHzpiqfF/PP8ryFg+WQmvIJOgufoZf/dFRi84jLmIEyncu6/JGSAE0KT/wg mJXg== X-Gm-Message-State: AOAM533OjG2IcNBPdodZvElIs9dD2yRbYiGTPllUNfBjNoc5JqrsNm+w OB4HrF/amFurbxNesFSZMNFRImFjkr0Khg== X-Google-Smtp-Source: ABdhPJwpc57SoRDXIX5d8IaLDDfT5P4wrvLbN01YEeyciY1guFoczFsEsaoHKqHg+Y3DjnlzYrjG/w== X-Received: by 2002:aed:2843:: with SMTP id r61mr3974212qtd.166.1606322436331; Wed, 25 Nov 2020 08:40:36 -0800 (PST) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id q62sm3058624qkf.86.2020.11.25.08.40.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 08:40:35 -0800 (PST) Subject: Re: [PATCH v3 1/8] config: Allow memory tagging to be enabled when configuring glibc To: "Richard Earnshaw (lists)" , Siddhesh Poyarekar , Richard Earnshaw , libc-alpha@sourceware.org References: <20201123154236.25809-1-rearnsha@arm.com> <20201123154236.25809-2-rearnsha@arm.com> <07c2b94b-b049-aa4a-7abd-3d0eff2cb711@gotplt.org> <065a8a2b-4c07-5cad-2747-110030072bce@linaro.org> <8db7bd72-c2ff-d41a-8993-a88cea5cbdc2@arm.com> From: Adhemerval Zanella Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= mQINBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABtElBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+iQI3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AquQINBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABiQIfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Message-ID: <58a0cf63-bb8a-1166-842c-9c354978b6f5@linaro.org> Date: Wed, 25 Nov 2020 13:40:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8db7bd72-c2ff-d41a-8993-a88cea5cbdc2@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 25 Nov 2020 16:40:38 -0000 On 25/11/2020 13:11, Richard Earnshaw (lists) wrote: > On 25/11/2020 15:12, Adhemerval Zanella via Libc-alpha wrote: >> >> >> On 25/11/2020 12:05, Siddhesh Poyarekar wrote: >>> On 11/23/20 9:12 PM, Richard Earnshaw via Libc-alpha wrote: >>>> >>>> This patch adds the configuration machinery to allow memory tagging to be >>>> enabled from the command line via the configure option --enable-memory-tagging. >>>> >>>> The current default is off, though in time we may change that once the API >>>> is more stable. >>>> --- >>>>   INSTALL             | 14 ++++++++++++++ >>>>   config.h.in         |  3 +++ >>>>   config.make.in      |  2 ++ >>>>   configure           | 17 +++++++++++++++++ >>>>   configure.ac        | 10 ++++++++++ >>>>   manual/install.texi | 13 +++++++++++++ >>>>   6 files changed, 59 insertions(+) >>>> >>>> diff --git a/INSTALL b/INSTALL >>>> index 2b00f80df5..f2476df6c0 100644 >>>> --- a/INSTALL >>>> +++ b/INSTALL >>>> @@ -142,6 +142,20 @@ if 'CFLAGS' is specified it must enable optimization.  For example: >>>>       non-CET processors.  '--enable-cet' has been tested for i686, >>>>       x86_64 and x32 on CET processors. >>>>   >>>> +'--enable-memory-tagging' >>>> +     Enable memory tagging support on architectures that support it. >>>> +     When the GNU C Library is built with this option then the resulting >>>> +     library will be able to control the use of tagged memory when >>>> +     hardware support is present by use of the tunable >>>> +     'glibc.memtag.enable'.  This includes the generation of tagged >>>> +     memory when using the 'malloc' APIs. >>>> + >>>> +     At present only AArch64 platforms with MTE provide this >>>> +     functionality, although the library will still operate (without >>>> +     memory tagging) on older versions of the architecture. >>>> + >>>> +     The default is to disable support for memory tagging. >>>> + >> >> Which is the downside of enabling it as default for AArch64 instead of >> a configure option? It would always be defined if --disable-tunables >> would be set, so one option would to enable iff tunables is already >> defined. > > > The default of off at present is largely due to this being new and I > didn't want to risk (too much) disturbing existing uses. My hope is > that the option default will change to on at some point in the > not-too-distant future. Right, I am asking because I would like avoid adding another build permutation which would another testing effort. To fully test this patch, it already requires a MTE enable hardware or emulation; I trying to going from 4 permutations (default glibc/no-MTE hw, MTE glibc/no-MTE hw, default glibc/MTE hw, MTE glibc/MTE hw) to just 2 (glibc/no-MTE hw, glibc/MTE hw). > >> >>>>  '--disable-profile' >>>>       Don't build libraries with profiling information.  You may want to >>>>       use this option if you don't plan to do profiling. >>>> diff --git a/config.h.in b/config.h.in >>>> index b823c8e080..2f4c626c19 100644 >>>> --- a/config.h.in >>>> +++ b/config.h.in >>>> @@ -160,6 +160,9 @@ >>>>  /* Define if __stack_chk_guard canary should be randomized at program startup.  */ >>>>  #undef ENABLE_STACKGUARD_RANDOMIZE >>>>   >>>> +/* Define if memory tagging support should be enabled.  */ >>>> +#undef _LIBC_MTAG >> >> The name is not really following the rest of other define, where >> they either use HAVE_* or USE_*. Also, I think there is no need >> to use an underscore prefix (it is usually used to define macro >> guards). > > It's mainly just sed work to change the name. Which do you want? HAVE_ > or USE_ ? I think USE_ would make more sense here, but I don't have a strong opinion.