From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 95E263851C3D for ; Fri, 27 Nov 2020 16:08:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 95E263851C3D Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3BB5F1516; Fri, 27 Nov 2020 08:08:55 -0800 (PST) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 821AE3F71F; Fri, 27 Nov 2020 08:08:54 -0800 (PST) Subject: Re: [PATCH v3 2/8] elf: Add a tunable to control use of tagged memory To: "H.J. Lu" , Siddhesh Poyarekar Cc: GNU C Library , Richard Earnshaw References: <20201123154236.25809-1-rearnsha@arm.com> <378cba09-12c1-59de-578a-1ca3a84015c5@foss.arm.com> <2a2cbd34-8dbc-34af-c5ee-b7d0ef5b48a7@gotplt.org> <26b8b11e-919a-b6e0-ff5f-51e724faffb2@foss.arm.com> <8ddb9604-5a6d-a656-0585-57a1b26c39f6@gotplt.org> <87e8b15f-8c86-4b2c-a5e4-3e70631ea505@gotplt.org> <23a8ad00-a376-48ae-cc6a-2684261146a1@foss.arm.com> <6173c59d-ee67-9499-ac61-c2dd37b56c67@foss.arm.com> <1938dee9-f8e5-ca9a-8f28-efb3ac91bf61@gotplt.org> <23462613-48c0-9fdf-aa89-18c98d9c6656@gotplt.org> <70937aae-cb56-50ad-dd1d-7e6b335ac927@gotplt.org> From: Richard Earnshaw Message-ID: Date: Fri, 27 Nov 2020 16:08:49 +0000 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3492.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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: Fri, 27 Nov 2020 16:08:56 -0000 On 27/11/2020 14:52, H.J. Lu via Libc-alpha wrote: > On Thu, Nov 26, 2020 at 6:45 PM Siddhesh Poyarekar wrote: >> >> On 11/26/20 10:49 PM, H.J. Lu wrote: >>> The first few questions are >> >> OK this is a good start: >> >>> 1. Where should binary markers be checked? >> >> At early startup alongside the cpu features resolution. We enable >> tagging if the CPU supports MTE and the marker is set. > > We won't know all the issues before we implement it. > >>> 2. How should binary marker checking work together with tunables? >> >> The presence of a binary marker enables tagging and a tunable should not >> be able to disable it. The exception would be systemwide tunables[1] >> where administrators could set sweeping policies for their systems, >> including disabling tagging systemwide if needed. > > The memory tag implementation should be independent of tunables. > Tunables should just turn on and off a few bits in the memory tag > implementation. Make the memory tag implementation depend on > tunables seems wrong to me. That shouldn't matter. The tunables are documented as not being stable and nothing else is exposed to the user; so if we want to change things later, there's nothing to stop that. R. > >> If binary marker is not present, tunables behave the way it is proposed >> in the patchset. >> >> Siddhesh >> >> [1] Vapourware alert! > > >