From patchwork Mon Sep 2 19:08:12 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13787644 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 E5400CA0ED3 for ; Mon, 2 Sep 2024 19:08:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 87DA08D0103; Mon, 2 Sep 2024 15:08:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 82E408D00E7; Mon, 2 Sep 2024 15:08:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CF268D0103; Mon, 2 Sep 2024 15:08:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4ED368D00E7 for ; Mon, 2 Sep 2024 15:08:46 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F16BE81B9D for ; Mon, 2 Sep 2024 19:08:45 +0000 (UTC) X-FDA: 82520735010.19.3674FD8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 34A6F40005 for ; Mon, 2 Sep 2024 19:08:43 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=t8jxrlHN; spf=pass (imf07.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725304031; 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: references:dkim-signature; bh=YqPsbCOjAYGqm1Zr71UnsmYg5x+lf7JiXOeO8aXTEtQ=; b=CO+sOQjgaiBHFIdaOaugdS6WDDz3r/woWvCiDlJK3PXD+6YaC15jjMrMMMK0apVrPzGppE ZCZJtOAUhu1auKRhL04XGKH6sdWCRLEumyIt/UNPsqIWGuS00yIkSvjDVwHzjEseCjEuK9 B4PQrdd5PLILJ+S5Q4zILAzr/PVFLYE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725304031; a=rsa-sha256; cv=none; b=Kx/s59UBXUbe8YcaHI+USATW2wCg7RrGj+5JPKx8pnMENKzBUwr9KwWBbvL5G9YvQk8ylI MUrQ+ucv7bUy6Hdq3VDNivcUiJvgggeonDDLMPIvQO9NaM3uz7Qk9gc3VrRhlTpRYQjCGQ Xj3viJNq5bD4rb0zVsVgQJtsMz7B1Rs= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=t8jxrlHN; spf=pass (imf07.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B11365C5786; Mon, 2 Sep 2024 19:08:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CCAEC4CEC2; Mon, 2 Sep 2024 19:08:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725304122; bh=Oas/y5WsR2uek3LQJA53gCtjxNPODnZnDS04Vmdm0SM=; h=From:Subject:Date:To:Cc:From; b=t8jxrlHNVdQXEDhwqdc20wAj+gPH80qUonuGgv2lMOAereLM62SZkpGPh6RAw9Q9b cBNdNdELgobbYczEeegAXNuBmkG7+MBKa3Udw2wp+tjLbthGJxD6C/atbKR7nQEKwI NAVDsSjvSJZ9+1oRX/kkvqkAIgsWJCEN3vAjweczQiDR8G8rv2/iGBjY0OqiwXsYOC 1YZQ4+Nhih70PVTlXd97kseJ3xxY4C8apxLBnSHWiBfctlrlY5bLTNsKDQhWc4cvZV gw+pLSbt1GGlFl6jRG9lXzrbyPWAt8owB6/wy3UdR0nEgwgZKF32T6/tL0RJDOum7q AtI7A5Vf8oy6Q== From: Mark Brown Subject: [PATCH 0/3] mm: Care about shadow stack guard gap when getting an unmapped area Date: Mon, 02 Sep 2024 20:08:12 +0100 Message-Id: <20240902-mm-generic-shadow-stack-guard-v1-0-9acda38b3dd3@kernel.org> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIABwN1mYC/x3MQQqDMBBA0avIrDuQqgHtVUoXSWaMgxhLplVBv LvB5Vv8f4ByFlZ4VQdkXkVlSQXPRwVhdCkyChVDberWdI3BecbIqUQBdXS0bKg/FyaMf5cJrQ/ Wd2S4twTl8c08yH7/35/zvADZttxrbwAAAA== To: Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Guo Ren , Huacai Chen , WANG Xuerui , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , "David S. Miller" , Andreas Larsson , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Chris Zankel , Max Filippov , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes Cc: Catalin Marinas , Will Deacon , Deepak Gupta , linux-arm-kernel@lists.infradead.org, linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, loongarch@lists.linux.dev, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, Mark Brown , Rick Edgecombe X-Mailer: b4 0.15-dev-37811 X-Developer-Signature: v=1; a=openpgp-sha256; l=2921; i=broonie@kernel.org; h=from:subject:message-id; bh=Oas/y5WsR2uek3LQJA53gCtjxNPODnZnDS04Vmdm0SM=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBm1g0tzzAYejDFf/YyyXU75xxYTOzlmhmKdU7A0Mjv QTPoE+GJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZtYNLQAKCRAk1otyXVSH0DS/B/ 9wL/O0zfApTjzan3whOoMvydnSM37kQyhnnpfHRjUqEv3U+31o7LNZtf8cgkcFnfvN/mcjg6zqfUbL sgE3gILwU/gP0rpIIqOBcdMi0yW/6RMxDx3KYAXsoMcW+HgREp4Jmstlc5mrqGzeY9D8bRILVJSjtt CxzlZDYaBGUyD6JX4rA4vmDkKdsx+ZsnFmkTKKS4DYRkMaU9mg1/cG7jWJa8t7opzkAXW5a9k1msEw fa0BXHW/LfCE9M6grMvRbR+VL7UOyIE9Bsha8/dsbR6EJN8gbJiRaqql1/7PoOt5/VXpmT+GO8cCfj ebeheDgkstF5WtU2RPgxVpDKwWWfI3 X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Rspamd-Queue-Id: 34A6F40005 X-Stat-Signature: nwjk9p4njumb5h4mkcsakee9kbxioqrw X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1725304123-5336 X-HE-Meta: U2FsdGVkX1+MGP3MlK1vCrJhq9Hf9dR34qClvtm6KoHfcI9JRgOA8ZL6bfWuQEJaUJ/iPeoggAoeHmtLg0weXGhKC8te/xuUi/a0taOf9JpPsQaENeLHVKaMlhv/T1J3BqhrTDty1wdGwydWropdIBAuh+s50ijMA0bm1gUDIdOIffCG7Nyo170PfyhtNrro2k4qYE1EeNxvkqwyaFCtkmXyK7tzlHX417myjCRJFw6gKdp0rqhlKz/66NIm/yo3mU49D0EFzClEQccWU/OA3xv2xvorP/RFlPpRr3wWJUEpEkvB96qZLrk9Mvv2uvD9+3CYSequ1UW8Mit8OEM4BDSU4MtY7cU2MkOv3LWcK29uHNPrUdJKzjVZpYZkD3pLGlrQ7TlRlO+RzGJv1p0YjCxi3pTZE3McHWnYpU7tq6Am9xKK1owJotMp/OosuHFwizfmCEWwuYmnIG1xrP3ULwzdvEZIFRQ7xfBdU0Ks+tUCi+CQaLMkXmqOqtMzMOSv4bnM6tMIGVazbc8gm8et7fIJHH7QS9mtTKdo2Ti/4g8kg0joRtlmPQbqLu/pW6QQv9c7YWMXez+5cLCEisV5pnxjlo2RKv6LiKUOXNTapqm6PRhjSwhvtxFe5lffh6BjTkFiEiwgnawY8V1tYT0o9MpEH/5IlWngQpxG8QkU+XU+7tJ6sYfCK6bJhR3jDQnKmOiWnjpds6bBqeAacYhuvWDdux+YzAqlDf0qCiNFfMEm9H7oNRgzfKeEQ5gHTfTzkTrVHzX4obHWNASckaC7UrU2FjlpbOz7i00CE5gqBmeg8FhBYX751nT5gkw2GyipytdXRTNmvMWksFT31aV9yTkpkbtmL3zwcUsirWcib9fkyYO8CZeQIi2nk3a86/ZyVJlzYIUPhshL5vn8vONZvur7J2xMvKlCbtwL5WkXJW8g/YzzVAwPAPMuge+f8YMPE28arAZEQfb8yzyewJD RNmT2c+C CZkFsFR8dUQ4d4RL55KmK94Ai8HMjSICwlXDi0idRLt1FqIdsnsi1q6vLOsn3TKkyN/r4snRjITpT51SfOP4a5Z7/ood0T0bZchbd0PIqsMfhewpoh8gFQZg3r5h/UDqQdPJ18I0Nj4UcjLCGY96gdIiPHuhpVZC7xh7Ra6aH+tOQnOqric61BpM6H4/lapiGk6HIY2ZN5C9O8uz7zhlt47gmeiLigNcl0CyY9lWBQFJ1xEmGPJ8BbDbKrHqTWDeVTDDLMvssSkgIfITodqbcf7IN8e1D4jFwpJk75Hs6n6tJNbhEdvmBZERVBQ== 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: As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow stack guard gap during placement") our current mmap() implementation does not take care to ensure that a new mapping isn't placed with existing mappings inside it's own guard gaps. This is particularly important for shadow stacks since if two shadow stacks end up getting placed adjacent to each other then they can overflow into each other which weakens the protection offered by the feature. On x86 there is a custom arch_get_unmapped_area() which was updated by the above commit to cover this case by specifying a start_gap for allocations with VM_SHADOW_STACK. Both arm64 and RISC-V have equivalent features and use the generic implementation of arch_get_unmapped_area() so let's make the equivalent change there so they also don't get shadow stack pages placed without guard pages. The arm64 and RISC-V shadow stack implementations are currently on the list: https://lore.kernel.org/r/20240829-arm64-gcs-v12-0-42fec94743 https://lore.kernel.org/lkml/20240403234054.2020347-1-debug@rivosinc.com/ Given the addition of the use of vm_flags in the generic implementation we also simplify the set of possibilities that have to be dealt with in the core code by making arch_get_unmapped_area() take vm_flags as standard. This is a bit invasive since the prototype change touches quite a few architectures but since the parameter is ignored the change is straightforward, the simplification for the generic code seems worth it. Signed-off-by: Mark Brown --- Mark Brown (3): mm: Make arch_get_unmapped_area() take vm_flags by default mm: Pass vm_flags to generic_get_unmapped_area() mm: Care about shadow stack guard gap when getting an unmapped area arch/alpha/kernel/osf_sys.c | 2 +- arch/arc/mm/mmap.c | 3 ++- arch/arm/mm/mmap.c | 7 +++--- arch/csky/abiv1/mmap.c | 3 ++- arch/loongarch/mm/mmap.c | 5 ++-- arch/mips/mm/mmap.c | 2 +- arch/parisc/kernel/sys_parisc.c | 5 ++-- arch/parisc/mm/hugetlbpage.c | 2 +- arch/powerpc/mm/book3s64/slice.c | 10 +++++--- arch/s390/mm/mmap.c | 4 +-- arch/sh/mm/mmap.c | 5 ++-- arch/sparc/kernel/sys_sparc_32.c | 2 +- arch/sparc/kernel/sys_sparc_64.c | 4 +-- arch/x86/include/asm/pgtable_64.h | 1 - arch/x86/kernel/sys_x86_64.c | 21 +++------------- arch/xtensa/kernel/syscall.c | 3 ++- include/linux/sched/mm.h | 27 ++++++++------------- mm/mmap.c | 51 ++++++++++++++++++--------------------- 18 files changed, 69 insertions(+), 88 deletions(-) --- base-commit: 7c626ce4bae1ac14f60076d00eafe71af30450ba change-id: 20240830-mm-generic-shadow-stack-guard-5bc5b8d0e95d Best regards,