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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 63C5CC433DF for ; Mon, 1 Jun 2020 08:55:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29CF4206C3 for ; Mon, 1 Jun 2020 08:55:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29CF4206C3 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 B699580007; Mon, 1 Jun 2020 04:55:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1C608E0006; Mon, 1 Jun 2020 04:55:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A57EA80007; Mon, 1 Jun 2020 04:55:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id 8DFAE8E0006 for ; Mon, 1 Jun 2020 04:55:44 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4ADDF40C7 for ; Mon, 1 Jun 2020 08:55:44 +0000 (UTC) X-FDA: 76880035008.11.spy38_6c3827b032153 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 29198180F8B80 for ; Mon, 1 Jun 2020 08:55:44 +0000 (UTC) X-HE-Tag: spy38_6c3827b032153 X-Filterd-Recvd-Size: 4994 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Mon, 1 Jun 2020 08:55:43 +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 BC2BC1FB; Mon, 1 Jun 2020 01:55:42 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0B5873F305; Mon, 1 Jun 2020 01:55:40 -0700 (PDT) Date: Mon, 1 Jun 2020 09:55:38 +0100 From: Dave Martin To: Catalin Marinas Cc: Szabolcs Nagy , linux-arch@vger.kernel.org, nd@arm.com, Peter Collingbourne , Kevin Brodsky , linux-mm@kvack.org, Evgenii Stepanov , Andrey Konovalov , Vincenzo Frascino , Will Deacon , Linux ARM Subject: Re: [PATCH v4 11/26] arm64: mte: Add PROT_MTE support to mmap() and mprotect() Message-ID: <20200601085536.GV5031@arm.com> References: <20200515171612.1020-1-catalin.marinas@arm.com> <20200515171612.1020-12-catalin.marinas@arm.com> <20200528091445.GA2961@gaia> <20200528110509.GA18623@arm.com> <20200528163412.GC2961@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200528163412.GC2961@gaia> User-Agent: Mutt/1.5.23 (2014-03-12) X-Rspamd-Queue-Id: 29198180F8B80 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Thu, May 28, 2020 at 05:34:13PM +0100, Catalin Marinas wrote: > On Thu, May 28, 2020 at 12:05:09PM +0100, Szabolcs Nagy wrote: > > The 05/28/2020 10:14, Catalin Marinas wrote: > > > On Wed, May 27, 2020 at 11:57:39AM -0700, Peter Collingbourne wrote: [...] Just jumping in on this point: > > > > 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) > > > > does this work even if the currently mapped stack is more than page_sz? > > determining the mapped main stack area is i think non-trivial to do in > > userspace (requires parsing /proc/self/maps or similar). > > Because of PROT_GROWSDOWN, the kernel adjusts the start of the range > down automatically. It is potentially problematic if the top of the > stack is more than a page away and you want the whole stack coloured. I > haven't run a test but my reading of the kernel code is that the stack > vma would be split in this scenario, so the range beyond sp+page_sz > won't have PROT_MTE set. > > My assumption is that if you do this during program start, the stack is > smaller than a page. Alternatively, could we use argv or envp to > determine the top of the user stack (the bottom is taken care of by the > kernel)? I don't think you can easily know when the stack ends, but perhaps it doesn't matter. >From memory, the initial stack looks like: argv/env strings AT_NULL auxv NULL env NULL argv argc <--- sp If we don't care about tagging the strings correctly, we could step to the end of auxv and tag down from there. If we do care about tagging the strings, there's probably no good way to find the end of the string area, other than looking up sp in /proc/self/maps. I'm not sure we should trust all past and future kernels to spit out the strings in a predictable order. Assuming that the last env string has the highest address does not sounds like a good idea to me. It would be easy for someone to break that assumption later without realising. If we're concerned about this, and reading /proc/self/auxv is deemed unacceptable (likely: some binaries need to work before /proc is mounted) then we could perhaps add a new auxv entry to report the stack base address to the user startup code. I don't think it matters if all this is "hard" for userspace: only the C library / runtime should be doing this. After libc startup, it's generally too late to do this kind of thing safely. [...] Cheers ---Dave