From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73510C433E0 for ; Thu, 11 Feb 2021 18:26:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B74F864E62 for ; Thu, 11 Feb 2021 18:26:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B74F864E62 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 39C106B014B; Thu, 11 Feb 2021 13:26:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 323DB6B014C; Thu, 11 Feb 2021 13:26:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EC786B014D; Thu, 11 Feb 2021 13:26:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0214.hostedemail.com [216.40.44.214]) by kanga.kvack.org (Postfix) with ESMTP id 021B86B014B for ; Thu, 11 Feb 2021 13:26:56 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B0E92BBE4 for ; Thu, 11 Feb 2021 18:26:56 +0000 (UTC) X-FDA: 77806818432.10.brass95_420e7472761a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 8829816A4BC for ; Thu, 11 Feb 2021 18:26:56 +0000 (UTC) X-HE-Tag: brass95_420e7472761a X-Filterd-Recvd-Size: 4227 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Thu, 11 Feb 2021 18:26:56 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C2E5764E15; Thu, 11 Feb 2021 18:26:52 +0000 (UTC) Date: Thu, 11 Feb 2021 18:26:50 +0000 From: Catalin Marinas To: Dave Hansen Cc: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Will Deacon , "H . J . Lu" , Andi Kleen , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 1/9] mm, arm64: Update PR_SET/GET_TAGGED_ADDR_CTRL interface Message-ID: <20210211182649.GB5238@arm.com> References: <20210205151631.43511-1-kirill.shutemov@linux.intel.com> <20210205151631.43511-2-kirill.shutemov@linux.intel.com> <20210211165748.GA5238@arm.com> <03b0f7d0-6b67-c48c-9250-ff4eadc221f2@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03b0f7d0-6b67-c48c-9250-ff4eadc221f2@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Dave, On Thu, Feb 11, 2021 at 09:06:12AM -0800, Dave Hansen wrote: > I noticed there are some ELF bits for ARM's BTI feature: > > GNU_PROPERTY_AARCH64_FEATURE_1_BTI > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/elf.h#n453 > > There's been talk of needing a similar set of bits on x86 for tagged > pointers (LAM). Do you have any plans to do something similar (ELF > property bits) for any of the pointer tagging features? Not at the moment but see below. Tagged addresses were supported on arm64 from day 0, though they were not used much (I think some JITs attempted to encode pointer types in the top byte). Until recently, we haven't allowed such tagged pointers as syscall arguments. The need for wider use of tagged pointers and the syscall ABI relaxation came from the ASan/HWASan work on LLVM and the subsequent Memory Tagging Extensions (MTE). With the latter, the user code doesn't need to be recompiled, only the right heap allocator to be loaded. So you could do an LD_PRELOAD to override malloc/free to return tagged pointers (I did this in the past to run a standard Debian + LTP testing). So we decided that it's easier for the C library to invoke a prctl() if needed rather than having some ELF property. MTE also requires additional control (like synchronous/asynchronous tag checking) which we added to the same prctl() to be done in a single call. That's, again, the decision of the C library together with using mmap(PROT_MTE) for the heap regions. That said, since HWASan requires code instrumentation, it would have been nice if some GNU property was present as not to mix&match such objects. I guess since it's mostly a debug feature, people didn't bother but it would probably fall apart if you mix it with MTE. With MTE, at some point we may deploy stack tagging which requires instrumentation of the function prologue/epilogue and mapping the stack with PROT_MTE. That's not widely used at the moment since such instructions are undef on previous CPU implementations. We may end up with an ELF annotation to distinguish such objects but I think that's still up for discussion. The reason for the BTI property was static binaries that needed PROT_BTI on their exec sections to be set by the kernel. MTE did not have such need (the C library would pass PROT_MTE explicitly on heap allocations) and neither did the top-byte-ignore feature. For the LAM feature, if the code is identical (e.g. it's the C library deciding whether malloc() returns tagged pointers), I don't see much use for an ELF annotation. However, if the plan is for something similar to HWASan with different code generation, it may be safer to just add a GNU note. -- Catalin