From patchwork Tue Mar 26 02:16: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: 13603256 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 603E0C54E58 for ; Tue, 26 Mar 2024 02:17:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF0006B0082; Mon, 25 Mar 2024 22:17:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC5FA6B0083; Mon, 25 Mar 2024 22:17:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8DD56B0085; Mon, 25 Mar 2024 22:17:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B71826B0082 for ; Mon, 25 Mar 2024 22:17:19 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 823D5160868 for ; Tue, 26 Mar 2024 02:17:19 +0000 (UTC) X-FDA: 81937578198.02.90260D4 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by imf02.hostedemail.com (Postfix) with ESMTP id A25F58000E for ; Tue, 26 Mar 2024 02:17:17 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KFHtKXJt; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf02.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 198.175.65.16 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711419437; 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=HSp2ErtUlG6FDL+J2vZ3AdaJVqkJe3IGkgcsYG7UeSc=; b=LaB1RjidaVrXVSl0PlJC+qEebQMDL9bo9Kuj7Lt3HFJ2PqDJA5ZQa3+k+uHdxBo0L40DsB wL5CE/L9WnXIQvYN/PN061fg1k5Tq4s2YUk6qifkR6Al+rlL58WN40CPQzpkrnpCZNIYM2 nzCVEp3pHRl5is4JTyGQD3lPMHb7lUA= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=KFHtKXJt; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf02.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 198.175.65.16 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711419437; a=rsa-sha256; cv=none; b=HDcrScqOoGfjag3RJDlDrIfainnK2aLPVx9cDNPmcVNy8QfkTAsCnmrTEX0soyNbqfBbX2 a/mcqY1OgnPbmBL9Mb0fA/tplEqP8cqdmrP0vzVjMQlDg8clRnmHKzhQ7+xdb8UqZoQgAL JY5F+FoMpJVx53oalMCPkvRXll+ehKM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711419438; x=1742955438; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=9GrifE+eAYRpRenFQJ6XnRK39adqukOR1ANPiFlRvJA=; b=KFHtKXJtTDNEC6fte3I5CbxThR23oLin/HiGmDAd3sScviz9h1W0e1Fk LnLdYhw1sSw8JoOvQpKoDYFCEEhGfrz1lve+DZWddZs2+ECgTbeHSwTa3 8ytq90QJD5DwOKqBslQd1uPGw0XQZ+ANc6Kp0Ys90MCb42oxmA861k+Zz NjIJWHE+QRzHMzD0ssC1V59xYGBcuan5XFZqsttODYIn8kKgrfm/uDYX4 C7VaD04ZVzfzq8BqYnlVJZKv69dkJMmDZqoQvgJpSuXk1iIZW2OkNKCn8 /vqfZz1bwnpgWkNlZOjlN4HuLUIeJZPce0JVy0r7yrsblIG3HrSsJHyCL Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11024"; a="6564195" X-IronPort-AV: E=Sophos;i="6.07,154,1708416000"; d="scan'208";a="6564195" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2024 19:17:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,154,1708416000"; d="scan'208";a="20489861" Received: from rpwilson-mobl.amr.corp.intel.com (HELO rpedgeco-desk4.intel.com) ([10.251.11.187]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2024 19:17:13 -0700 From: Rick Edgecombe To: Liam.Howlett@oracle.com, akpm@linux-foundation.org, bp@alien8.de, broonie@kernel.org, christophe.leroy@csgroup.eu, 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 Cc: rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v4 00/14] Cover a guard gap corner case Date: Mon, 25 Mar 2024 19:16:42 -0700 Message-Id: <20240326021656.202649-1-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Rspamd-Queue-Id: A25F58000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: nt6d5ttgfa5dg5cd1amwd6enwx7qj4dw X-HE-Tag: 1711419437-731722 X-HE-Meta: U2FsdGVkX1828+Q37Pk0cvHSfeTO8v5WOsBUTMbduSquNrnoLw3dlkop/ZeH/kbZ/BDp1vFPD/PpkX/qEgWIVvr+SUAqOk9QSkbRzT9tKlC8ve8hUPJpmCIj9XsrlzrHtG21VBhTCN9n2ALqMzRo8I/tTnw3nf1cZzTivVqbRtXu/yyHcvlwpXDPQcQQTDkW+3XeKyk99h8IFCEYLMX3S+ET4lNMcEixQT3+l6WjQHhkKGU1jFLV1WprNUPHm4IH8CjvkmWTZ+lHl8jrM3SuRmnDnieCICK/fsx4p7LEJ9h13VglsvL8yy9DL0rs58bv3szHrp6+9lytyejr68PDBI7jU/vMqNbgXuDzVx+IdUnATxt1BJUJyTew/cNYIuREgNzu5hLALNt04lfGJPx+WK02IhYwR12pQ7FWqT9606k86D/YN+8USDbLcIc+QgT8MCy0cVWv27jwapTLfr0tFn3WHYl7pM4/Af9alJeMtbLK5Jp5Hn+18lby4wa3UDBvLpIZvRG9skVpHK1viUxf+jPiVgA2U0X5hba7RE+VF4Rs23IpCeoMoP3Du+WtMQInzGCG2FfIDy0cz+V27+iH9gobM7KPVdAMxG4zTzO7cRzNRpjAWpw4SW/7kS3qzy7kaN7ZT08tm0//Ec2+BGBIChBA9fXBojgB+6FzHMd5ZCmY6Yj4ABc2PpsMwvB5sqR5WlMZQ+NLxksH+h4zCzJmUs/gq3XBzEc9ELaO3sB2usRr/PVjEHgHVZ+7dg1K6nm/gcvX2enUzIiWapMJGIzbz0tuSlkAQPUa03LvtkSSlRxQYgAxpBNRSq3pc6NkbOOviFJ56pyKZHQ0QnhNQLqz1Q== 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: Hi, For v4, is just some small non-functional changes from Christophe Leroy, including splitting two patches. Also, rebase to v6.9-rc1. This included converting two new mm->get_unmapped_area() callsites that popped up. v3: https://lore.kernel.org/lkml/20240312222843.2505560-1-rick.p.edgecombe@intel.com/ v2: https://lore.kernel.org/lkml/20240226190951.3240433-1-rick.p.edgecombe@intel.com/ v1: https://lore.kernel.org/lkml/20240215231332.1556787-1-rick.p.edgecombe@intel.com/ ======= In working on x86’s shadow stack feature, I came across some limitations around the kernel’s handling of guard gaps. AFAICT these limitations are not too important for the traditional stack usage of guard gaps, but have bigger impact on shadow stack’s usage. And now in addition to x86, we have two other architectures implementing shadow stack like features that plan to use guard gaps. I wanted to see about addressing them, but I have not worked on mmap() placement related code before, so would greatly appreciate if people could take a look and point me in the right direction. The nature of the limitations of concern is as follows. In order to ensure guard gaps between mappings, mmap() would need to consider two things: 1. That the new mapping isn’t placed in an any existing mapping’s guard gap. 2. That the new mapping isn’t placed such that any existing mappings are not in *its* guard gaps Currently mmap never considers (2), and (1) is not considered in some situations. When not passing an address hint, or passing one without MAP_FIXED_NOREPLACE, (1) is enforced. With MAP_FIXED_NOREPLACE, (1) is not enforced. With MAP_FIXED, (1) is not considered, but this seems to be expected since MAP_FIXED can already clobber existing mappings. For MAP_FIXED_NOREPLACE I would have guessed it should respect the guard gaps of existing mappings, but it is probably a little ambiguous. In this series I just tried to add enforcement of (2) for the normal (no address hint) case and only for the newer shadow stack memory (not stacks). The reason is that with the no-address-hint situation, landing next to a guard gap could come up naturally and so be more influencable by attackers such that two shadow stacks could be adjacent without a guard gap. Where as the address-hint scenarios would require more control - being able to call mmap() with specific arguments. As for why not just fix the other corner cases anyway, I thought it might have some greater possibility of affecting existing apps. Thanks, Rick Rick Edgecombe (14): proc: Refactor pde_get_unmapped_area as prep mm: Switch mm->get_unmapped_area() to a flag mm: Introduce arch_get_unmapped_area_vmflags() mm: Remove export for get_unmapped_area() mm: Use get_unmapped_area_vmflags() thp: Add thp_get_unmapped_area_vmflags() csky: Use initializer for struct vm_unmapped_area_info parisc: Use initializer for struct vm_unmapped_area_info powerpc: Use initializer for struct vm_unmapped_area_info treewide: Use initializer for struct vm_unmapped_area_info mm: Take placement mappings gap into account x86/mm: Implement HAVE_ARCH_UNMAPPED_AREA_VMFLAGS x86/mm: Care about shadow stack guard gap during placement selftests/x86: Add placement guard gap test for shstk arch/alpha/kernel/osf_sys.c | 5 +- arch/arc/mm/mmap.c | 4 +- arch/arm/mm/mmap.c | 5 +- arch/csky/abiv1/mmap.c | 12 +- arch/loongarch/mm/mmap.c | 3 +- arch/mips/mm/mmap.c | 3 +- arch/parisc/kernel/sys_parisc.c | 6 +- arch/powerpc/mm/book3s64/slice.c | 20 ++-- arch/s390/mm/hugetlbpage.c | 9 +- arch/s390/mm/mmap.c | 9 +- arch/sh/mm/mmap.c | 5 +- arch/sparc/kernel/sys_sparc_32.c | 3 +- arch/sparc/kernel/sys_sparc_64.c | 20 ++-- arch/sparc/mm/hugetlbpage.c | 9 +- arch/x86/include/asm/pgtable_64.h | 1 + arch/x86/kernel/cpu/sgx/driver.c | 2 +- arch/x86/kernel/sys_x86_64.c | 42 +++++-- arch/x86/mm/hugetlbpage.c | 9 +- arch/x86/mm/mmap.c | 4 +- drivers/char/mem.c | 2 +- drivers/dax/device.c | 6 +- fs/hugetlbfs/inode.c | 11 +- fs/proc/inode.c | 10 +- fs/ramfs/file-mmu.c | 2 +- include/linux/huge_mm.h | 11 ++ include/linux/mm.h | 12 +- include/linux/mm_types.h | 6 +- include/linux/sched/coredump.h | 5 +- include/linux/sched/mm.h | 22 ++++ io_uring/io_uring.c | 2 +- kernel/bpf/arena.c | 2 +- kernel/bpf/syscall.c | 2 +- mm/debug.c | 6 - mm/huge_memory.c | 26 +++-- mm/mmap.c | 106 +++++++++++++----- mm/shmem.c | 11 +- mm/util.c | 6 +- .../testing/selftests/x86/test_shadow_stack.c | 67 ++++++++++- 38 files changed, 312 insertions(+), 174 deletions(-)