linux.git/arch/xtensa/kernel/syscall.c, branch v6.12.80

mm: make arch_get_unmapped_area() take vm_flags by default

2024-09-09T23:39:13+00:00

Patch series "mm: Care about shadow stack guard gap when getting an
unmapped area", v2.

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.


This patch (of 3):

When we introduced arch_get_unmapped_area_vmflags() in 961148704acd ("mm:
introduce arch_get_unmapped_area_vmflags()") we did so as part of properly
supporting guard pages for shadow stacks on x86_64, which uses a custom
arch_get_unmapped_area().  Equivalent features are also present on both
arm64 and RISC-V, both of which use the generic implementation of
arch_get_unmapped_area() and will require equivalent modification there. 
Rather than continue to deal with having two versions of the functions
let's bite the bullet and have all implementations of
arch_get_unmapped_area() take vm_flags as a parameter.

The new parameter is currently ignored by all implementations other than
x86.  The only caller that doesn't have a vm_flags available is
mm_get_unmapped_area(), as for the x86 implementation and the wrapper used
on other architectures this is modified to supply no flags.

No functional changes.

Link: https://lkml.kernel.org/r/20240904-mm-generic-shadow-stack-guard-v2-0-a46b8b6dc0ed@kernel.org
Link: https://lkml.kernel.org/r/20240904-mm-generic-shadow-stack-guard-v2-1-a46b8b6dc0ed@kernel.org
Signed-off-by: Mark Brown 
Acked-by: Lorenzo Stoakes 
Reviewed-by: Liam R. Howlett 
Acked-by: Helge Deller 	[parisc]
Cc: Alexander Gordeev 
Cc: Andreas Larsson 
Cc: Borislav Petkov 
Cc: Christian Borntraeger 
Cc: Christophe Leroy 
Cc: Chris Zankel 
Cc: Dave Hansen 
Cc: David S. Miller 
Cc: "Edgecombe, Rick P" 
Cc: Gerald Schaefer 
Cc: Guo Ren 
Cc: Heiko Carstens 
Cc: "H. Peter Anvin" 
Cc: Huacai Chen 
Cc: Ingo Molnar 
Cc: Ivan Kokshaysky 
Cc: James Bottomley 
Cc: John Paul Adrian Glaubitz 
Cc: Matt Turner 
Cc: Max Filippov 
Cc: Michael Ellerman 
Cc: Naveen N Rao 
Cc: Nicholas Piggin 
Cc: Richard Henderson 
Cc: Rich Felker 
Cc: Russell King 
Cc: Sven Schnelle 
Cc: Thomas Bogendoerfer 
Cc: Thomas Gleixner 
Cc: Vasily Gorbik 
Cc: Vineet Gupta 
Cc: Vlastimil Babka 
Cc: WANG Xuerui 
Cc: Yoshinori Sato 
Signed-off-by: Andrew Morton

xtensa: remove vma linked list walks

2022-09-27T02:46:20+00:00

Use the VMA iterator instead.  Since VMA can no longer be NULL in the
loop, then deal with out-of-memory outside the loop.  This means a
slightly longer run time in the failure case (-ENOMEM) - it will run to
the end of the VMAs before erroring instead of in the middle of the loop.

Link: https://lkml.kernel.org/r/20220906194824.2110408-37-Liam.Howlett@oracle.com
Signed-off-by: Matthew Wilcox (Oracle) 
Signed-off-by: Liam R. Howlett 
Reviewed-by: Davidlohr Bueso 
Tested-by: Yu Zhao 
Cc: Catalin Marinas 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: SeongJae Park 
Cc: Sven Schnelle 
Cc: Vlastimil Babka 
Cc: Will Deacon 
Signed-off-by: Andrew Morton

xtensa: syscalls: switch to generic syscalltbl.sh

2021-04-04T22:39:03+00:00

Many architectures duplicate similar shell scripts.

This commit converts xtensa to use scripts/syscalltbl.sh.

Signed-off-by: Masahiro Yamada 
Message-Id: <20210301153656.363839-2-masahiroy@kernel.org>
Signed-off-by: Max Filippov

xtensa: stop filling syscall array with sys_ni_syscall

2021-04-04T22:39:02+00:00

arch/xtensa/kernel/syscalls/syscalltbl.sh fills missing syscall numbers
with sys_ni_syscall.

So, the generated arch/xtensa/include/generated/asm/syscall_table.h
has no hole.

Hence, the line:

  [0 ... __NR_syscalls - 1] = (syscall_t)&sys_ni_syscall,

is meaningless.

The number of generated __SYSCALL() macros is the same as __NR_syscalls
(this is 442 as of v5.11).

Hence, the array size, [__NR_syscalls] is unneeded.

The designated initializer, '[nr] =', is also unneeded.

This file does not need to know __NR_syscalls. Drop the unneeded
 include directive.

Signed-off-by: Masahiro Yamada 
Message-Id: <20210301153656.363839-1-masahiroy@kernel.org>
Signed-off-by: Max Filippov

xtensa: implement syscall tracepoints

2018-12-17T21:50:25+00:00

Add TIF_SYSCALL_TRACEPOINT flag definition; add _TIF_SYSCALL_TRACEPOINT
to _TIF_WORK_MASK. Call trace_sys_enter from do_syscall_trace_enter and
trace_sys_exit from do_syscall_trace_leave when TIF_SYSCALL_TRACEPOINT
flag is set.
Add declaration of sys_call_table to arch/xtensa/include/asm/syscall.h
Add definition of NR_syscalls to arch/xtensa/include/asm/unistd.h
Select HAVE_SYSCALL_TRACEPOINTS.

This change allows tracing each syscall entry and exit through the
ftrace mechanism.

Signed-off-by: Max Filippov

xtensa: generate uapi header and syscall table header files

2018-12-03T07:45:41+00:00

System call table generation script must be run to gener-
ate unistd_32.h and syscall_table.h files. This patch will
have changes which will invokes the script.

This patch will generate unistd_32.h and syscall_table.h
files by the syscall table generation script invoked by
xtensa/Makefile and the generated files against the removed
files must be identical.

The generated uapi header file will be included in uapi/-
asm/unistd.h and generated system call table header file
will be included by kernel/syscall.c file.

Signed-off-by: Firoz Khan 
Signed-off-by: Max Filippov

xtensa: add __NR_syscalls along with __NR_syscall_count

2018-12-03T07:45:21+00:00

__NR_syscall_count macro holds the number of system call
exist in xtensa architecture. We have to change the value
of __NR_syscall_count, if we add or delete a system call.

One of the patch in this patch series has a script which
will generate a uapi header based on syscall.tbl file.
The syscall.tbl file contains the total number of system
calls information. So we have two option to update __NR-
_syscall_count value.

1. Update __NR_syscall_count in asm/unistd.h manually by
   counting the no.of system calls. No need to update __NR-
   _syscall_count until we either add a new system call or
   delete existing system call.

2. We can keep this feature it above mentioned script,
   that will count the number of syscalls and keep it in
   a generated file. In this case we don't need to expli-
   citly update __NR_syscall_count in asm/unistd.h file.

The 2nd option will be the recommended one. For that, I
added the __NR_syscalls macro in uapi/asm/unistd.h.
The macro __NR_syscalls also added for making the name
convention same across all architecture. While __NR_syscalls
isn't strictly part of the uapi, having it as part of the
generated header to simplifies the implementation. We also
need to enclose this macro with #ifdef __KERNEL__ to avoid
side effects.

Signed-off-by: Firoz Khan 
Signed-off-by: Max Filippov 
[Max: Drop __NR_syscall_count completely, use __NR_syscalls instead]

mm: add ksys_fadvise64_64() helper; remove in-kernel call to sys_fadvise64_64()

2018-04-02T18:16:10+00:00

Using the ksys_fadvise64_64() helper allows us to avoid the in-kernel
calls to the sys_fadvise64_64() syscall. The ksys_ prefix denotes that
this function is meant as a drop-in replacement for the syscall. In
particular, it uses the same calling convention as ksys_fadvise64_64().

Some compat stubs called sys_fadvise64(), which then just passed through
the arguments to sys_fadvise64_64(). Get rid of this indirection, and call
ksys_fadvise64_64() directly.

This patch is part of a series which removes in-kernel calls to syscalls.
On this basis, the syscall entry path can be streamlined. For details, see
http://lkml.kernel.org/r/20180325162527.GA17492@light.dominikbrodowski.net

Cc: Andrew Morton 
Cc: linux-mm@kvack.org
Signed-off-by: Dominik Brodowski

mm: larger stack guard gap, between vmas

2017-06-19T13:50:20+00:00

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov 
Original-patch-by: Michal Hocko 
Signed-off-by: Hugh Dickins 
Acked-by: Michal Hocko 
Tested-by: Helge Deller  # parisc
Signed-off-by: Linus Torvalds

sched/headers: Prepare for new header dependencies before moving more code to

2017-03-02T07:42:30+00:00

We are going to split more MM APIs out of , which
will have to be picked up from a couple of .c files.

The APIs that we are going to move are:

  arch_pick_mmap_layout()
  arch_get_unmapped_area()
  arch_get_unmapped_area_topdown()
  mm_update_next_owner()

Include the header in the files that are going to need it.

Acked-by: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar