On Wed, 2023-09-13 at 12:18 -0700, Sohil Mehta wrote:
On 9/11/2023 2:10 PM, Edgecombe, Rick P wrote:
On Mon, 2023-09-11 at 18:02 +0000, Sohil Mehta wrote:
diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
b/arch/powerpc/kernel/syscalls/syscall.tbl
index 20e50586e8a2..2767b8a42636 100644
--- a/arch/powerpc/kernel/syscalls/syscall.tbl
+++ b/arch/powerpc/kernel/syscalls/syscall.tbl
@@ -539,3 +539,4 @@
450 nospu set_mempolicy_home_node sys_set_mempolicy
_hom
e_node
451 common cachestat sys_cachestat
452 common fchmodat2 sys_fchmodat2
+453 common map_shadow_stack sys_map_shadow_st
ack
I noticed in powerpc, the not implemented syscalls are manually
mapped
to sys_ni_syscall. It also has some special extra sys_ni_syscall()
implementation bits to handle both ARCH_HAS_SYSCALL_WRAPPER and
!ARCH_HAS_SYSCALL_WRAPPER. So wondering if it might need special
treatment. Did you see those parts?
Thanks for pointing this out. Powerpc seems to be unique in their
handling of not implemented syscalls. Maybe it's because of their
special casing of the ARCH_HAS_SYSCALL_WRAPPER.
The code below in arch/powerpc/include/asm/syscalls.h suggests to me
that it should be safe to map map_shadow_stack() to sys_ni_syscall()
and
the special handling will be taken care of.
#ifndef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
long sys_ni_syscall(void);
#else
long sys_ni_syscall(const struct pt_regs *regs);
#endif
I don't quite understand the underlying reasoning for it though. Do
you
have any additional insight into how we should handle this?
I am thinking of doing the following in the next iteration unless
someone chimes in and says otherwise.
--- a/arch/powerpc/kernel/syscalls/syscall.tbl
+++ b/arch/powerpc/kernel/syscalls/syscall.tbl
@@ -539,4 +539,4 @@
450 nospu set_mempolicy_home_node
sys_set_mempolicy_home_node
451 common cachestat sys_cachestat
452 common fchmodat2 sys_fchmodat2
-453 common map_shadow_stack sys_map_shadow_stack
+453 common map_shadow_stack sys_ni_syscall
It might have something to do with that powerpc's COND_SYSCALL()
implementation only defines the struct pt_regs variety, but TBH I get a
bit lost when I get to the inline assembly symbol definitions parts and
how it all ties together.
Doing powerpc's version as sys_ni_syscall seems to be consistent at
least, and makes sense with respect to the code you quoted.
