From patchwork Tue Mar 12 22:28:42 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Edgecombe, Rick P" X-Patchwork-Id: 13590677 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 AA476C54E58 for ; Tue, 12 Mar 2024 22:29:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C01E18E0029; Tue, 12 Mar 2024 18:29:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B89E78E0011; Tue, 12 Mar 2024 18:29:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B6CB8E0029; Tue, 12 Mar 2024 18:29:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 80B6E8E0011 for ; Tue, 12 Mar 2024 18:29:14 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 545FD1A052D for ; Tue, 12 Mar 2024 22:29:14 +0000 (UTC) X-FDA: 81889829028.21.0C29BFA Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) by imf24.hostedemail.com (Postfix) with ESMTP id 76A7718000E for ; Tue, 12 Mar 2024 22:29:12 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KFkMD0S2; spf=pass (imf24.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710282552; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LhppU4CMZhZm5EP9rRLemF2K+Rv21AF3TMMjKMbUW+w=; b=Sbh4JfjYP9cNEAKqZVjR7QKuShArmLFF6pX2XHbT9pu9B1k0tSMHsUnmNUisc0wwkz7xxj RcjvfvNwNwZZm5HW0Y4kPOD9Ib24Cy82o7cOPsG4+/fDMoAenTwpBpkeRVMnDkN0f7ui+T VjESOgybLMr2x6eKL3pde501GNL4AAY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710282552; a=rsa-sha256; cv=none; b=tPyHlzFEpM1p9o/pcjadaCl22MYEa6lOrhkwSj2Mln6niy1tu995BuIBuWSDTX6LSzrcFe knV5yd6sPmDnVOz7NT53hHgnqhVvhLZXh5tTjjqX2dSkhiwba0sZ+a0NPlDEhGXbLQZvb3 sQ2FpeviKp3FvZSUiLKkeEzVDv+YXC0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KFkMD0S2; spf=pass (imf24.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 192.198.163.15 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710282553; x=1741818553; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TSd5WZe/p2AZRhCNpPLqqksEWjeny0UmWfCVRjzSme8=; b=KFkMD0S2eIIxirGr5fkC6iN2CaYHv07DbUPEqQhi7g1nZUTqygH3ReiD tdA/2Dvo6ub5NXbY0HGp4pYoRErIz0i3Ngb5/Hc0XRF45qgh7qyKit6Jp o4Ij/8wLlherlO/UE8PyX1P9JCxEfizzs/PT23zI53h5A5UnrP94racV2 nt4eGiRAjV79JmjGYer/S4kEmHl52S33baFog7VBCQ67LPT6tBNpjuT6i iI5U9ATbXuC8Wj3Te9XPfx90+3adyoyxIktP26HQjvXeqDtgCl4SCpHXJ Wd3GTvPi4BTWcqldF849fMk5rSoUhEptdgSzb9jNWfiXDZ9r+Gbm7wUbM g==; X-IronPort-AV: E=McAfee;i="6600,9927,11011"; a="5192070" X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208";a="5192070" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 15:29:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,119,1708416000"; d="scan'208";a="16356883" Received: from gargayus-mobl1.amr.corp.intel.com (HELO rpedgeco-desk4.intel.com) ([10.255.231.196]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2024 15:29:04 -0700 From: Rick Edgecombe To: Liam.Howlett@oracle.com, akpm@linux-foundation.org, bp@alien8.de, broonie@kernel.org, dave.hansen@linux.intel.com, debug@rivosinc.com, hpa@zytor.com, keescook@chromium.org, kirill.shutemov@linux.intel.com, luto@kernel.org, mingo@redhat.com, peterz@infradead.org, tglx@linutronix.de, x86@kernel.org, christophe.leroy@csgroup.eu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, rick.p.edgecombe@intel.com Subject: [PATCH v3 11/12] x86/mm: Care about shadow stack guard gap during placement Date: Tue, 12 Mar 2024 15:28:42 -0700 Message-Id: <20240312222843.2505560-12-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240312222843.2505560-1-rick.p.edgecombe@intel.com> References: <20240312222843.2505560-1-rick.p.edgecombe@intel.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: 76A7718000E X-Rspam-User: X-Stat-Signature: zkrcquu5bgi6p1ir6gd63r9paf99frdx X-Rspamd-Server: rspam03 X-HE-Tag: 1710282552-327537 X-HE-Meta: U2FsdGVkX1820EmTR4lMBbaKvJCd2EQjb7IBFf7Hhxs9ZXfkBuA9XpmuxaQWi545uSbMTstbIb7Dwj0xpDDC2BKZN1ulTylUVWiEVOUJk8peRlV0ZZeiYR8bnNYte9yxfKJtikH36FvTNCQn6ykZuvVyozxpy5xdboDRwu6bShzggZDvjwJ61OQY/YaU6axih8ntLfrOO+BtXSNkP/XO0zw/tswbqv17KGkmwwY3AsvT8KDRD922o2F8goEIfUMTGAuws54uZtP45xCQF2VV0jUD7NsgTah9m8Nc34YncsHv7eGeEq/Fdp/aPAHFRpDmL+wSwGG5wrtNh4IEEOSX084EHtctfMDk/ufZw1ZFewIRFEbT05nSpR9w+EAemiCoFEHhudDhm3rYY2nA8YGSYJU1+I3HxNeL8SJEWIPgBtcVzx72tpCu4xzBkjEoq0PB4Egg485X8l7XcIB0Ram+KaBlGPz137VhVyBy0dX0Dg2qfvFDqfqzGW35enKtBMe1k8gdV5a+Nkuq8dO21hWKbZ9hnVe967HM9eJDlVQHBgEJrXI0W/ZjAulsvKW6vXHv1WasShBdRnIsrrL60k88OlLTguEfpZzR80RD2B+x+FfR5w3KqfQwezy7y158LLMR1WgRe8+TBCb14vv5rRaM94kmSrHqRXLhBx2qlfTE+sexYl3Wbk/Xsw5A7wJijDsRE3zva/zo7Y1uqSRUrtcxggMvn+KHHRQ3K/tyHHRUd4IEGz6Uq+uFcksoMx10eudm9sJ1fpl8baBJQ3i5VeKI6ZYFHh+0PVtGAPGSKpPauEMa0MgIGsA0gkHNWzTLyQrlHFzESQ7zWiXrzddSqXWgK3i2r7pBuO8H 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: List-Subscribe: List-Unsubscribe: When memory is being placed, mmap() will take care to respect the guard gaps of certain types of memory (VM_SHADOWSTACK, VM_GROWSUP and VM_GROWSDOWN). In order to ensure guard gaps between mappings, mmap() needs to consider two things: 1. That the new mapping isn’t placed in an any existing mappings guard gaps. 2. That the new mapping isn’t placed such that any existing mappings are not in *its* guard gaps. The long standing behavior of mmap() is to ensure 1, but not take any care around 2. So for example, if there is a PAGE_SIZE free area, and a mmap() with a PAGE_SIZE size, and a type that has a guard gap is being placed, mmap() may place the shadow stack in the PAGE_SIZE free area. Then the mapping that is supposed to have a guard gap will not have a gap to the adjacent VMA. Now that the vm_flags is passed into the arch get_unmapped_area()'s, and vm_unmapped_area() is ready to consider it, have VM_SHADOW_STACK's get guard gap consideration for scenario 2. Signed-off-by: Rick Edgecombe --- arch/x86/kernel/sys_x86_64.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c index d6fbc4dd08ef..964cb435710e 100644 --- a/arch/x86/kernel/sys_x86_64.c +++ b/arch/x86/kernel/sys_x86_64.c @@ -119,6 +119,14 @@ static void find_start_end(unsigned long addr, unsigned long flags, *end = task_size_64bit(addr > DEFAULT_MAP_WINDOW); } +static inline unsigned long stack_guard_placement(vm_flags_t vm_flags) +{ + if (vm_flags & VM_SHADOW_STACK) + return PAGE_SIZE; + + return 0; +} + unsigned long arch_get_unmapped_area_vmflags(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags, vm_flags_t vm_flags) @@ -148,6 +156,7 @@ arch_get_unmapped_area_vmflags(struct file *filp, unsigned long addr, unsigned l info.low_limit = begin; info.high_limit = end; info.align_offset = pgoff << PAGE_SHIFT; + info.start_gap = stack_guard_placement(vm_flags); if (filp) { info.align_mask = get_align_mask(); info.align_offset += get_align_bits(); @@ -197,6 +206,7 @@ arch_get_unmapped_area_topdown_vmflags(struct file *filp, unsigned long addr0, info.low_limit = PAGE_SIZE; info.high_limit = get_mmap_base(0); + info.start_gap = stack_guard_placement(vm_flags); /* * If hint address is above DEFAULT_MAP_WINDOW, look for unmapped area