Re: [PATCH 2/2] arch: Reserve map_shadow_stack() syscall number for all architectures

"Edgecombe, Rick P" <[email protected]>
Newsgroups gmane.linux.ports.m68k,gmane.linux.kernel,gmane.linux.kernel.cross-arch,gmane.linux.kernel.api,gmane.linux.kernel.perf.user,gmane.linux.ports.sparc,gmane.linux.ports.ia64,gmane.linux.ports.parisc,gmane.linux.ports.sh.devel,gmane.linux.ports.ppc64.devel,gmane.linux.ports.mips,gmane.linux.ports.alpha,gmane.linux.ports.arm.kernel
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.