From patchwork Mon Feb 26 19:09: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: 13572722 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 CF2C0C48BF6 for ; Mon, 26 Feb 2024 19:10:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 426244401B0; Mon, 26 Feb 2024 14:10:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D6C444017F; Mon, 26 Feb 2024 14:10:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C5B74401B0; Mon, 26 Feb 2024 14:10:02 -0500 (EST) 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 1A20444017F for ; Mon, 26 Feb 2024 14:10:02 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B3A2CA0C31 for ; Mon, 26 Feb 2024 19:10:01 +0000 (UTC) X-FDA: 81834895002.11.10EAF48 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf09.hostedemail.com (Postfix) with ESMTP id DE074140010 for ; Mon, 26 Feb 2024 19:09:58 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=H16luBrl; spf=pass (imf09.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=rick.p.edgecombe@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708974600; a=rsa-sha256; cv=none; b=w1zt3IhscQG5l4Xxi9/JKhFTBCaLts9VrGbygNukd8kleZ+NWfte8CTAH9bfjQWqoOWVhD dYcb9w56i7uIlYnkEiJws7+3rUVJz4yVzgNtigyaZNWoFP3kec/fJrmEP+JfIWcrpG2FjM o3k9sraTJ0+rjsM7fTqLLnTagpVg/t4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=H16luBrl; spf=pass (imf09.hostedemail.com: domain of rick.p.edgecombe@intel.com designates 198.175.65.12 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=1708974600; 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=i1+VofUSE53WCxMZAh1JyI6itwKktqEccx3EUhjWjEM=; b=aT11wTWAwTcm7yGk33SKV2uz7J/2HdMK1pTbqn6CtZquDucGiA0buj2agnxIoOvSblj4w/ P/kJwDAecW/LUh07TgL5+7u4Jmkfs/AWaEvS2P49uIbsA9oHCw7hY7pPGbeQjCj3IILqbj YVxbDMBtp1LD6H/9Ut3Mw12ZywdM3Ys= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708974599; x=1740510599; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=WLPsNTUS0rffo4BsiNOi5ZgQL+HawDXmRJXW4mh1RDM=; b=H16luBrlB7WXCUwXLs7lLL+FWLM1RZp/2PxGXX56SzkRjMHe7NsfUcRz IOiNHjnQ8X+QTEkrmV0D+p4NC7B8wdbXksYkSusCEXzTWuJhkdkr8rel8 k/SyTxejeGGMcaJMR7dkMCMuWFpMyQxSle8wlmaf1kZsYnIH3pJIlsa1O p5wxdHZe86aPV5fIRQOGngSJsNvINGD4fXE0et7daf84qTJLt8FuBigBv rT9meR5cTsUW5uJYyvP0NaGFDKnwsYgpQfyN5yrS7NanfFcLV3Tn+PbWn H6ukiyGq1oORVnjatIIyAV3KYddE0WJ8HtdnmAcVJ8c6KOzEetIr7EXPh w==; X-IronPort-AV: E=McAfee;i="6600,9927,10996"; a="14721324" X-IronPort-AV: E=Sophos;i="6.06,186,1705392000"; d="scan'208";a="14721324" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Feb 2024 11:09:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,186,1705392000"; d="scan'208";a="6911439" Received: from bdmirand-mobl.amr.corp.intel.com (HELO rpedgeco-desk4.intel.com) ([10.251.3.213]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Feb 2024 11:09:56 -0800 From: Rick Edgecombe To: Liam.Howlett@oracle.com, akpm@linux-foundation.org, debug@rivosinc.com, broonie@kernel.org, kirill.shutemov@linux.intel.com, keescook@chromium.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, luto@kernel.org, peterz@infradead.org, hpa@zytor.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: rick.p.edgecombe@intel.com Subject: [PATCH v2 0/9] Cover a guard gap corner case Date: Mon, 26 Feb 2024 11:09:42 -0800 Message-Id: <20240226190951.3240433-1-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DE074140010 X-Stat-Signature: yuoxfn9zthuha8gpgdx3j7kkzh1ggde4 X-Rspam-User: X-HE-Tag: 1708974598-122243 X-HE-Meta: U2FsdGVkX1/OJWM0mJa2hqLKhLAPqTr0Yq1o70GUzMdXo0nsmakvzUbTCn0WoHSXj2D0vABfnMVPOgK3jNufP6SW/0eCaHmCzkFpJyuusprl6S+bVDXvE7c/B+jvTrICwGwxDQFu6mR0Tzq+3G0p36k6wXRuv61sQMj19P2+TVYnY29nNWza7ThlmHrXhSBsHUDeuHFRAd+MidJuQfBc74Q2XMN0PCWC3v94Vmzjnm/s6l4MGuq33utmQVo/95Su1TR5ecPfA8/B8NzboH6pYlRU3Ei6i00VrsHQ9SqaL2WMLAKLUo2IHkDwis+AckIze3cngot1b0HjrFBJHcJ2Xo3jPNW+E+/MqYyp2ZmCR7E2YnPVBiXpEBz9fVoKXjQNfP105ABV26SgHsxfcMJm2Bo/Cymd4Esrfrm15I9JNrd9LVtsCu/tyHHQP8+v7AHhLglZTLpK+xe9DkDKFm/WZ5hAN/YdEK9BwlkvOm2ekB3+ikcVe2miMdor6NMQz8WyHQIVJ4CjsYN9iYVw+LPbh8Jn0bVefezXVbXVihvDtL7BziOh+aoNs5b9kwDKUVX2huVHcDxCaUbyp0PyPvQ0yYyij3vO/9F7FtDQy4q/Y5IlVw95j2muSH3wsjgOPee/jvKsHLP3bH2mLU5QLpkO70+QO6caH/wiXJDvsDdDUPWWRpHWctXHDfTcvdLPro8uF5+2D2HkU5Zxx04Z2wPdlOEUlJH6F8yYpOOwlEiwcoa4nOWZuUY9y7qjBJgLnI3TorPqS2FLoR0hMi6OrXXrIeAn5JKmSD1zMR+wQvJGdvwkd8dvLh/nSaKRPKtS5gfMjbaRfUeHmyXu1H52HxwB6Q== 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 v2, the notable change is a bug fix to not clobber the MMF_TOPDOWN during fork. In the RFC this resulted in fork() children that didn't exec getting the map up behavior, which included the stress-ng bigheap test. It turns out much of the 4% improvement seen was due to the bottomup mapping direction. With the fix, the performance benefit was a less surprising ~1%. Other than that, Kirill's style feedback was addressed. There were no functional changes (other than the bug). Link to 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 (9): mm: Switch mm->get_unmapped_area() to a flag mm: Introduce arch_get_unmapped_area_vmflags() mm: Use get_unmapped_area_vmflags() thp: Add thp_get_unmapped_area_vmflags() mm: Initialize 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 | 2 +- arch/arc/mm/mmap.c | 2 +- arch/arm/mm/mmap.c | 4 +- arch/csky/abiv1/mmap.c | 2 +- arch/loongarch/mm/mmap.c | 2 +- arch/mips/mm/mmap.c | 2 +- arch/parisc/kernel/sys_parisc.c | 2 +- arch/powerpc/mm/book3s64/slice.c | 4 +- arch/s390/mm/hugetlbpage.c | 6 +- arch/s390/mm/mmap.c | 8 +- arch/sh/mm/mmap.c | 4 +- arch/sparc/kernel/sys_sparc_32.c | 2 +- arch/sparc/kernel/sys_sparc_64.c | 19 ++-- arch/sparc/mm/hugetlbpage.c | 6 +- arch/x86/include/asm/pgtable_64.h | 1 + arch/x86/kernel/cpu/sgx/driver.c | 2 +- arch/x86/kernel/sys_x86_64.c | 39 +++++-- arch/x86/mm/hugetlbpage.c | 6 +- arch/x86/mm/mmap.c | 4 +- drivers/char/mem.c | 2 +- drivers/dax/device.c | 6 +- fs/hugetlbfs/inode.c | 6 +- fs/proc/inode.c | 15 +-- 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 +- mm/debug.c | 6 -- mm/huge_memory.c | 23 ++-- mm/mmap.c | 101 +++++++++++++----- mm/shmem.c | 11 +- mm/util.c | 6 +- .../testing/selftests/x86/test_shadow_stack.c | 67 +++++++++++- 36 files changed, 298 insertions(+), 122 deletions(-)