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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54E62C6FD1C for ; Tue, 14 Mar 2023 07:19:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6EC16B0072; Tue, 14 Mar 2023 03:19:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D1FF76B0074; Tue, 14 Mar 2023 03:19:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC03E6B0075; Tue, 14 Mar 2023 03:19:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AC3386B0072 for ; Tue, 14 Mar 2023 03:19:51 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7388D160B78 for ; Tue, 14 Mar 2023 07:19:51 +0000 (UTC) X-FDA: 80566654182.13.B6A00C2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id BDE041A0003 for ; Tue, 14 Mar 2023 07:19:49 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Xc+htRg4; spf=pass (imf19.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678778389; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rIWTC7yXp9PEv6417l7cobReu9qJmp1rh47LDNTE68g=; b=qc1lvCroBo7OhHNVtReX+rOu5rx4RTBHMKjW1PH5u4sFx3mcxkyMPFhWM82UGMKDVnakto vV96X+PIShlzxy9qDTzG+X6o0AVh2SIKpTgyTUzzZhhYlh7jNOYGTpUJiKxAXcw7gSk6V2 3Z9ZNK7RD0N48tHxahtSP9b8YorlFu4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Xc+htRg4; spf=pass (imf19.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678778389; a=rsa-sha256; cv=none; b=X4ZXWZPPaR4B/qPwld6FHN1fObh3+XBvUslFgHHeuLZh9ha2O3UhaDw+9yoaOz/8YPQa8Y oUfUQeZLIwPW1kDZnvQDbSCZUVuOGd7MO+AcMpc9Ga9jDjw4uPwKOVvlB8MqLCyoN36vIe pwqf1pyx317I6eyAya2jcKR/XMV2y4o= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AF896615F1; Tue, 14 Mar 2023 07:19:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18B34C433EF; Tue, 14 Mar 2023 07:19:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678778388; bh=rEcwpr6ZTgtGaQrka2qK+7yPmKYXTmYdMJswZJ4beXE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xc+htRg4jwkaQ1NdwL15ZlqUDMviGCnMWy9asoPgzTkQsycHYyOuxImk+2fwxRjJg ANSpQgtaUXSm5JxSsOEx18+zhZX4fFXLwaw89hdRjNu+43fhg7cT2exl6XR/v50yQx PVdG/eSVNK9EXDfcDdUf3czRPirAefJxegCSQo0VUSKps7q9gqtPs+f87B4YaMdsgM pnULmDVF+F93AQhI8H5MAQdQAK2mCfBbSxV6ARQ0lKbuqqyuK7HcPID8wRiIB/R/S1 ksVWWlmvLvg/6n6asn34itV+OVlWruZdWD4KY/wTe8Y6R7U2VUCKtue6AvIarS974i U01UkRTpXIeng== Date: Tue, 14 Mar 2023 09:19:25 +0200 From: Mike Rapoport To: Deepak Gupta Cc: Szabolcs Nagy , Rick Edgecombe , x86@kernel.org, "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H . J . Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , Weijiang Yang , "Kirill A . Shutemov" , John Allen , kcc@google.com, eranian@google.com, jamorris@linux.microsoft.com, dethoma@microsoft.com, akpm@linux-foundation.org, Andrew.Cooper3@citrix.com, christina.schimpe@intel.com, david@redhat.com, nd@arm.com, al.grant@arm.com Subject: Re: [PATCH v7 33/41] x86/shstk: Introduce map_shadow_stack syscall Message-ID: References: <20230227222957.24501-1-rick.p.edgecombe@intel.com> <20230227222957.24501-34-rick.p.edgecombe@intel.com> <20230309185511.GA1964069@debug.ba.rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230309185511.GA1964069@debug.ba.rivosinc.com> X-Rspamd-Queue-Id: BDE041A0003 X-Stat-Signature: 477kw9hmom7s3cxghs341ttbrccyt6yo X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678778389-976369 X-HE-Meta: U2FsdGVkX1/9FiAAq9wJuuSpKNJNgnjLlNoD0XKxPp4OFzxAT7XPXGXIb/cEJhLj8hzuzhQSnTpQxF54VDqSCNBLWnxSI8flQMGi3qQrgSsCma7LyaYgL6My/yaO6/kqBfnD3uPQvIR3hkTM9+vONHpfua/ZwFQPaOJaL66Hue0QKGOxZG+BiJ6KduTpDI28sQWKPz2foFSWZWjOVtDqJ5mxtMHd9h/b3TOkI2UwIdwZVGwByZWWfnXi8K/TwCGUF24riRo4emOxHc/0CM3RN7Ryura3AbJ3oC0MWTNY5uZuIKVFhpxLTqfmYTu/AJwMLzO25FJ3wU/qauRS1XZLdfNQAeMyG4CM4oc18QqmGgYzeSiLtoV0/kYoBdwkgmSG3/Y2jW1LGL360ClyyrKHeVLiQEk5DVWVr2EkacRaOMJd4g1KqG5mlJaXeNr+PQGISPCujQoT7Y/331vdn4ORle3nfEZkOmSnoc7wYk6zlFLi9gj3FFwTFV347+Dne7Mrov44SciUvfFBJhbJQyz9pMRODl5QaQ8Jw5QgSiQafTKj9Pox+QzP17gwpYybmr4tGaI+GG6nLAxtjop75lRfdVXClReHcsNqhsVUMw1R9sB/ha1WfKCPx8dRP1TQ2KvQjXuwVLSvKYuuePfmd8S6T/PAKjtiwJ6l4PGxwiCuL7iUe5sUqTCi1x//LAQphDyZ+SVYxMQZ7g/3jtYCOJXbvwMX850iT6qGOLUNSu2DMaXD3vfO6FuAwjQ0gp/7W6/S6jdHumyMAmGBTZrNzMJu4gb5B5LgnvqO217oq500bjdXffzpUIqtgnKp28Mev61pryTz0Cb7Enf3C9ebldU1bCzDPrBz0VxeLpgHFUJNazReaHEAQUkLWNv7IfHIYDndQ8Og6q3MwSjbrCj7Pff/vtQ6ZhQUpBAqqQ+ZuFdakuAb5/CbtMztSLyQYqS4g0ryvU8DMeHzh+kcOrmn1O0 3RNncTNr VsL4oP3xj9KBFazwVcMQhEIlKo6xuR3g5tOiTda7uymqKoDIi+7pNLO6sS0YwPLeXpP10fufpyPDDD65W9QIHuc/GxlzZzTeK86vrlJxm09QQyZtjeTU1bBkexs3Du5N1Xy63A79zTyvAPas9I4zLUD4qexlwdAPmM2nYLypHgsQAHc+SNsL/5fYy6fxcsSaXTEymNXPmTNSBEHykp9DEUFr6S6kbg/W5+0W/eavLgr3OfTtZ5myAjC15FCIMoxA5t2d3mn/WMjGgqokHbM3RQbT6CHUWPWtlIOBbC6JFC+W9uYHEjQH/2g3o26J+O1qjZ2AaIR+3qnIWypOiz2w60yQRaG1/X1knp692w29Kcbz08NSdIux1pz8fvARJ8/qOAVDDm7nbAHKXbr14s1ASjawtw7bq2LJIFLmjhMgOG5j2IT7k1xC9mhvQV1UMWF5bpmTd/xyV+cQyzepaRrx6tCapfSY3OosfwboowABYtGHa7LVdDq/Z4pbNT1gLw9U1GrsK7YYX8VeoWIBBCHy+THgCSAHMYzDaMbDJhQQNKOCfT2o= 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, On Thu, Mar 09, 2023 at 10:55:11AM -0800, Deepak Gupta wrote: > On Thu, Mar 02, 2023 at 05:22:07PM +0000, Szabolcs Nagy wrote: > > The 02/27/2023 14:29, Rick Edgecombe wrote: > > > Previously, a new PROT_SHADOW_STACK was attempted, > > ... > > > So rather than repurpose two existing syscalls (mmap, madvise) that don't > > > quite fit, just implement a new map_shadow_stack syscall to allow > > > userspace to map and setup new shadow stacks in one step. While ucontext > > > is the primary motivator, userspace may have other unforeseen reasons to > > > setup it's own shadow stacks using the WRSS instruction. Towards this > > > provide a flag so that stacks can be optionally setup securely for the > > > common case of ucontext without enabling WRSS. Or potentially have the > > > kernel set up the shadow stack in some new way. > > ... > > > The following example demonstrates how to create a new shadow stack with > > > map_shadow_stack: > > > void *shstk = map_shadow_stack(addr, stack_size, SHADOW_STACK_SET_TOKEN); > > > > i think > > > > mmap(addr, size, PROT_READ, MAP_ANON|MAP_SHADOW_STACK, -1, 0); > > > > could do the same with less disruption to users (new syscalls > > are harder to deal with than new flags). it would do the > > guard page and initial token setup too (there is no flag for > > it but could be squeezed in). > > Discussion on this topic in v6 > https://lore.kernel.org/all/20230223000340.GB945966@debug.ba.rivosinc.com/ > > Again I know earlier CET patches had protection flag and somehow due to pushback > on mailing list, it was adopted to go for special syscall because no one else > had shadow stack. > > Seeing a response from Szabolcs, I am assuming arm4 would also want to follow > using mmap to manufacture shadow stack. For reference RFC patches for risc-v shadow stack, > use a new protection flag = PROT_SHADOWSTACK. > https://lore.kernel.org/lkml/20230213045351.3945824-1-debug@rivosinc.com/ > > I know earlier discussion had been that we let this go and do a re-factor later as other > arch support trickle in. But as I thought more on this and I think it may just be > messy from user mode point of view as well to have cognition of two different ways of > creating shadow stack. One would be special syscall (in current libc) and another `mmap` > (whenever future re-factor happens) > > If it's not too late, it would be more wise to take `mmap` > approach rather than special `syscall` approach. I disagree. Having shadow stack flags for mmap() adds unnecessary complexity to the core-mm, while having a dedicated syscall hides all the details in the architecture specific code. Another reason to use a dedicated system call allows for better extensibility if/when we'd need to update the way shadow stack VMA is created. As for the userspace convenience, it is anyway required to add special code for creating the shadow stack and it wouldn't matter if that code would use mmap(NEW_FLAG) or map_shadow_stack(). > > most of the mmap features need not be available (EINVAL) when > > MAP_SHADOW_STACK is specified. > > > > the main drawback is running out of mmap flags so extension > > is limited. (but the new syscall has limitations too). -- Sincerely yours, Mike.