linux-kernel - [PATCH 3/3] mm: Care about shadow stack guard gap when getting an unmapped area

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240902-mm-generic-shadow-stack-guard-v1-3-9acda38b3dd3@kernel.org>
Date: Mon, 02 Sep 2024 20:08:15 +0100
From: Mark Brown <broonie@...nel.org>
To: Richard Henderson <richard.henderson@...aro.org>, 
 Ivan Kokshaysky <ink@...assic.park.msu.ru>, 
 Matt Turner <mattst88@...il.com>, Vineet Gupta <vgupta@...nel.org>, 
 Russell King <linux@...linux.org.uk>, Guo Ren <guoren@...nel.org>, 
 Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>, 
 "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>, 
 Helge Deller <deller@....de>, Michael Ellerman <mpe@...erman.id.au>, 
 Nicholas Piggin <npiggin@...il.com>, 
 Christophe Leroy <christophe.leroy@...roup.eu>, 
 Naveen N Rao <naveen@...nel.org>, 
 Alexander Gordeev <agordeev@...ux.ibm.com>, 
 Gerald Schaefer <gerald.schaefer@...ux.ibm.com>, 
 Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, 
 Christian Borntraeger <borntraeger@...ux.ibm.com>, 
 Sven Schnelle <svens@...ux.ibm.com>, 
 Yoshinori Sato <ysato@...rs.sourceforge.jp>, Rich Felker <dalias@...c.org>, 
 John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
 "David S. Miller" <davem@...emloft.net>, 
 Andreas Larsson <andreas@...sler.com>, Thomas Gleixner <tglx@...utronix.de>, 
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
 Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
 "H. Peter Anvin" <hpa@...or.com>, Chris Zankel <chris@...kel.net>, 
 Max Filippov <jcmvbkbc@...il.com>, 
 Andrew Morton <akpm@...ux-foundation.org>, 
 "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
 Vlastimil Babka <vbabka@...e.cz>, 
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Catalin Marinas <catalin.marinas@....com>, 
 Will Deacon <will@...nel.org>, Deepak Gupta <debug@...osinc.com>, 
 linux-arm-kernel@...ts.infradead.org, linux-alpha@...r.kernel.org, 
 linux-kernel@...r.kernel.org, linux-snps-arc@...ts.infradead.org, 
 linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org, 
 loongarch@...ts.linux.dev, linux-parisc@...r.kernel.org, 
 linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org, 
 linux-sh@...r.kernel.org, sparclinux@...r.kernel.org, linux-mm@...ck.org, 
 Mark Brown <broonie@...nel.org>, 
 Rick Edgecombe <rick.p.edgecombe@...el.com>
Subject: [PATCH 3/3] mm: Care about shadow stack guard gap when getting an
 unmapped area

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.

Architectures which do not have this feature will define VM_SHADOW_STACK
to VM_NONE and hence be unaffected.

Suggested-by: Rick Edgecombe <rick.p.edgecombe@...el.com>
Signed-off-by: Mark Brown <broonie@...nel.org>
---
 mm/mmap.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/mm/mmap.c b/mm/mmap.c
index b06ba847c96e..902c482b6084 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1753,6 +1753,14 @@ static unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info)
 	return gap;
 }

+static inline unsigned long stack_guard_placement(vm_flags_t vm_flags)
+{
+	if (vm_flags & VM_SHADOW_STACK)
+		return PAGE_SIZE;
+
+	return 0;
+}
+
 /*
  * Search for an unmapped address range.
  *
@@ -1814,6 +1822,7 @@ generic_get_unmapped_area(struct file *filp, unsigned long addr,
 	info.length = len;
 	info.low_limit = mm->mmap_base;
 	info.high_limit = mmap_end;
+	info.start_gap = stack_guard_placement(vm_flags);
 	return vm_unmapped_area(&info);
 }

@@ -1863,6 +1872,7 @@ generic_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
 	info.length = len;
 	info.low_limit = PAGE_SIZE;
 	info.high_limit = arch_get_mmap_base(addr, mm->mmap_base);
+	info.start_gap = stack_guard_placement(vm_flags);
 	addr = vm_unmapped_area(&info);

 	/*

-- 
2.39.2