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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 C40A9C433E0 for ; Mon, 1 Jun 2020 14:45:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 964462074B for ; Mon, 1 Jun 2020 14:45:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Kl8qggqs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 964462074B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PuPM85TzyXH26R0DqL+9teTBVuvXDQRAufpLz71sQn0=; b=Kl8qggqszIZ3vF UJQX5M1o8b2oK8Kiux+AIWsfb9yvprMpPMF2ezlvZ4Z/QtMMqw3XQuRRothXnpdowm+AINfgLfef1 sZT/midRMSU7QtQvFh/WvBusGWMwfnvgnuq7uxrGnV+pbGjoENF2WSAGriO3RvUaNOV6YrzCnoNBx 0A4X+fddMt4aKrd1G1MtL0w1L4emPNMY4h+k0oSQMvcISMm+/B4KG7JkCYhNL+gYTCIZsvaEzFbRA RGqyRdkPqSyyLGDrjgJLVm27fmhWQxNuNbt1q0Qkz9iQlyAG4Bc/+QvF2MYNXkaxG5kFQGPyhjGaR kNkIJcObVc6G4mfMcOUg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jflhJ-0008Gj-Ra; Mon, 01 Jun 2020 14:45:53 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jflhG-0008GB-At for linux-arm-kernel@lists.infradead.org; Mon, 01 Jun 2020 14:45:52 +0000 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 2804455D; Mon, 1 Jun 2020 07:45:49 -0700 (PDT) Received: from gaia (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 78FC73F305; Mon, 1 Jun 2020 07:45:47 -0700 (PDT) Date: Mon, 1 Jun 2020 15:45:45 +0100 From: Catalin Marinas To: Dave Martin Subject: Re: [PATCH v4 11/26] arm64: mte: Add PROT_MTE support to mmap() and mprotect() Message-ID: <20200601144544.GC23419@gaia> 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> <20200601085536.GV5031@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200601085536.GV5031@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200601_074550_463765_064CF304 X-CRM114-Status: GOOD ( 28.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Vincenzo Frascino , Will Deacon , Szabolcs Nagy , Andrey Konovalov , Kevin Brodsky , linux-mm@kvack.org, Linux ARM , nd@arm.com, Peter Collingbourne , Evgenii Stepanov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 01, 2020 at 09:55:38AM +0100, Dave P Martin wrote: > 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: > > > > > 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. I don't think we care about tagging whatever the kernel places on the stack since the argv/envp pointers are untagged. An mprotect(PROT_MTE) may or may not cover the environment but it shouldn't matter as the kernel clears the tags on the corresponding pages anyway. AFAIK stack tagging works by colouring a stack frame on function entry and clearing the tags on return. We would only hit a problem if the function issuing mprotect(sp, PROT_MTE) on and its callers already assumed a PROT_MTE stack. Without PROT_MTE, an STG would be write-ignore, so subsequently turning it on would lead to a mismatch between the pointer and the allocation tags. So PROT_MTE turning on should happen very early in the user process startup code before any code with stack tagging enabled. Whether you reach the top of the stack with such mprotect() doesn't really matter since up to that point there should not be any use of stack tagging. If that's not possible, for example the glibc code setting up the stack was compiled to stack tagging itself, the kernel would have to enable it when the user process starts. However, I'd only do this based on some ELF note. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel