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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 0A842C433E0 for ; Thu, 28 May 2020 09:14:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BF0FD208E4 for ; Thu, 28 May 2020 09:14:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF0FD208E4 Authentication-Results: mail.kernel.org; dmarc=none (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 466168001A; Thu, 28 May 2020 05:14:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 416E480010; Thu, 28 May 2020 05:14:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32CF58001A; Thu, 28 May 2020 05:14:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0113.hostedemail.com [216.40.44.113]) by kanga.kvack.org (Postfix) with ESMTP id 1928B80010 for ; Thu, 28 May 2020 05:14:51 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CDBC7C5B8 for ; Thu, 28 May 2020 09:14:50 +0000 (UTC) X-FDA: 76865567940.07.crown85_2a4040ec79a13 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id B1DDC1803F9B8 for ; Thu, 28 May 2020 09:14:50 +0000 (UTC) X-HE-Tag: crown85_2a4040ec79a13 X-Filterd-Recvd-Size: 3648 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 May 2020 09:14:50 +0000 (UTC) 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 710DF31B; Thu, 28 May 2020 02:14:49 -0700 (PDT) Received: from gaia (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E25D23F6C4; Thu, 28 May 2020 02:14:47 -0700 (PDT) Date: Thu, 28 May 2020 10:14:45 +0100 From: Catalin Marinas To: Peter Collingbourne Cc: Linux ARM , linux-mm@kvack.org, linux-arch@vger.kernel.org, Will Deacon , Dave P Martin , Vincenzo Frascino , Szabolcs Nagy , Kevin Brodsky , Andrey Konovalov , Evgenii Stepanov Subject: Re: [PATCH v4 11/26] arm64: mte: Add PROT_MTE support to mmap() and mprotect() Message-ID: <20200528091445.GA2961@gaia> References: <20200515171612.1020-1-catalin.marinas@arm.com> <20200515171612.1020-12-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: B1DDC1803F9B8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: On Wed, May 27, 2020 at 11:57:39AM -0700, Peter Collingbourne wrote: > On Fri, May 15, 2020 at 10:16 AM Catalin Marinas > wrote: > > To enable tagging on a memory range, the user must explicitly opt in via > > a new PROT_MTE flag passed to mmap() or mprotect(). Since this is a new > > memory type in the AttrIndx field of a pte, simplify the or'ing of these > > bits over the protection_map[] attributes by making MT_NORMAL index 0. > > Should the userspace stack always be mapped as if with PROT_MTE if the > hardware supports it? Such a change would be invisible to non-MTE > aware userspace since it would already need to opt in to tag checking > via prctl. This would let userspace avoid a complex stack > initialization sequence when running with stack tagging enabled on the > main thread. I don't think the stack initialisation is that difficult. On program startup (can be the dynamic loader). Something like (untested): register unsigned long stack asm ("sp"); unsigned long page_sz = sysconf(_SC_PAGESIZE); mprotect((void *)(stack & ~(page_sz - 1)), page_sz, PROT_READ | PROT_WRITE | PROT_MTE | PROT_GROWSDOWN); (the essential part it PROT_GROWSDOWN so that you don't have to specify a stack lower limit) I don't like enabling this by default since it will have a small cost even if the application doesn't enable tag checking. The kernel would still have to zero the tags when mapping the stack and preserve them when swapping out. Another case where this could go wrong is if we want enable some quiet monitoring of user programs: the libc enables PROT_MTE on heap allocations but keeps tag checking disabled as it doesn't want any SIGSEGV; the kernel could enable async TCF and log any faults (rate-limited). Default PROT_MTE stack would get in the way. Anyway, this use-case is something for the future, so far these patches rely on the user solely driving the tag checking mode. I'm fine, however, with enabling PROT_MTE on the main stack based on some ELF note. -- Catalin