Re: [PATCH 2/2] arch: Reserve map_shadow_stack() syscall number for all architectures
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "Mehta, Sohil" <sohil.mehta@xxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "linux-arch@xxxxxxxxxxxxxxx" <linux-arch@xxxxxxxxxxxxxxx>, "linux-api@xxxxxxxxxxxxxxx" <linux-api@xxxxxxxxxxxxxxx>
- Subject: Re: [PATCH 2/2] arch: Reserve map_shadow_stack() syscall number for all architectures
- From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
- Date: Wed, 13 Sep 2023 22:05:27 +0000
- Accept-language: en-US
- Cc: "svens@xxxxxxxxxxxxx" <svens@xxxxxxxxxxxxx>, "catalin.marinas@xxxxxxx" <catalin.marinas@xxxxxxx>, "schwab@xxxxxxxxxxxxxx" <schwab@xxxxxxxxxxxxxx>, "brgerst@xxxxxxxxx" <brgerst@xxxxxxxxx>, "alexander.shishkin@xxxxxxxxxxxxxxx" <alexander.shishkin@xxxxxxxxxxxxxxx>, "linux-perf-users@xxxxxxxxxxxxxxx" <linux-perf-users@xxxxxxxxxxxxxxx>, "x86@xxxxxxxxxx" <x86@xxxxxxxxxx>, "dalias@xxxxxxxx" <dalias@xxxxxxxx>, "monstr@xxxxxxxxx" <monstr@xxxxxxxxx>, "borntraeger@xxxxxxxxxxxxx" <borntraeger@xxxxxxxxxxxxx>, "dave.hansen@xxxxxxxxxxxxxxx" <dave.hansen@xxxxxxxxxxxxxxx>, "christophe.leroy@xxxxxxxxxx" <christophe.leroy@xxxxxxxxxx>, "mark.rutland@xxxxxxx" <mark.rutland@xxxxxxx>, "glaubitz@xxxxxxxxxxxxxxxxxxx" <glaubitz@xxxxxxxxxxxxxxxxxxx>, "lukas.bulwahn@xxxxxxxxx" <lukas.bulwahn@xxxxxxxxx>, "rdunlap@xxxxxxxxxxxxx" <rdunlap@xxxxxxxxxxxxx>, "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>, "hca@xxxxxxxxxxxxx" <hca@xxxxxxxxxxxxx>, "linux@xxxxxxxxxxxxxxx" <linux@xxxxxxxxxxxxxxx>, "sparclinux@xxxxxxxxxxxxxxx" <sparclinux@xxxxxxxxxxxxxxx>, "jolsa@xxxxxxxxxx" <jolsa@xxxxxxxxxx>, "arnd@xxxxxxxx" <arnd@xxxxxxxx>, "ebiederm@xxxxxxxxxxxx" <ebiederm@xxxxxxxxxxxx>, "Lutomirski, Andy" <luto@xxxxxxxxxx>, "linux-ia64@xxxxxxxxxxxxxxx" <linux-ia64@xxxxxxxxxxxxxxx>, "linux-parisc@xxxxxxxxxxxxxxx" <linux-parisc@xxxxxxxxxxxxxxx>, "linux-sh@xxxxxxxxxxxxxxx" <linux-sh@xxxxxxxxxxxxxxx>, "akpm@xxxxxxxxxxxxxxxxxxxx" <akpm@xxxxxxxxxxxxxxxxxxxx>, "linuxppc-dev@xxxxxxxxxxxxxxxx" <linuxppc-dev@xxxxxxxxxxxxxxxx>, "mpe@xxxxxxxxxxxxxx" <mpe@xxxxxxxxxxxxxx>, "geert@xxxxxxxxxxxxxx" <geert@xxxxxxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, "James.Bottomley@xxxxxxxxxxxxxxxxxxxxx" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, "peterz@xxxxxxxxxxxxx" <peterz@xxxxxxxxxxxxx>, "ink@xxxxxxxxxxxxxxxxxxxx" <ink@xxxxxxxxxxxxxxxxxxxx>, "linux-m68k@xxxxxxxxxxxxxxxxxxxx" <linux-m68k@xxxxxxxxxxxxxxx>, "broonie@xxxxxxxxxx" <broonie@xxxxxxxxxx>, "tsbogend@xxxxxxxxxxxxxxxx" <tsbogend@xxxxxxxxxxxxxxxx>, "Hunter, Adrian" <adrian.hunter@xxxxxxxxx>, "acme@xxxxxxxxxx" <acme@xxxxxxxxxx>, "ysato@xxxxxxxxxxxxxxxxxxxx" <ysato@xxxxxxxxxxxxx>, "deller@xxxxxx" <deller@xxxxxx>, "debug@xxxxxxxxxxxx" <debug@xxxxxxxxxxxx>, "rmclure@xxxxxxxxxxxxx" <rmclure@xxxxxxxxxxxxx>, "gor@xxxxxxxxxxxxx" <gor@xxxxxxxxxxxxx>, "slyich@xxxxxxxxx" <slyich@xxxxxxxxx>, "npiggin@xxxxxxxxx" <npiggin@xxxxxxxxx>, "agordeev@xxxxxxxxxxxxx" <agordeev@xxxxxxxxxxxxx>, "chris@xxxxxxxxxx" <chris@xxxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "linux-mips@xxxxxxxxxxxxxxx" <linux-mips@xxxxxxxxxxxxxxx>, "linux-alpha@xxxxxxxxxxxxxxx" <linux-alpha@xxxxxxxxxxxxxxx>, "mattst88@xxxxxxxxx" <mattst88@xxxxxxxxx>, "linux-s390@xxxxxxxxxxxxxxx" <linux-s390@xxxxxxxxxxxxxxx>, "linux-arm-kernel@xxxxxxxxxxxxxxxxxxx" <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, "bp@xxxxxxxxx" <bp@xxxxxxxxx>, "jcmvbkbc@xxxxxxxxx" <jcmvbkbc@xxxxxxxxx>, "richard.henderson@xxxxxxxxxx" <richard.henderson@xxxxxxxxxx>, "irogers@xxxxxxxxxx" <irogers@xxxxxxxxxx>, "namhyung@xxxxxxxxxx" <namhyung@xxxxxxxxxx>, "will@xxxxxxxxxx" <will@xxxxxxxxxx>, "davem@xxxxxxxxxxxxx" <davem@xxxxxxxxxxxxx>
- In-reply-to: <29da2af0-5c88-f937-a9b6-db2d5f481321@intel.com>
- References: <20230911180210.1060504-1-sohil.mehta@intel.com> <20230911180210.1060504-3-sohil.mehta@intel.com> <8b7106881fa227a64b4e951c6b9240a7126ac4a2.camel@intel.com> <29da2af0-5c88-f937-a9b6-db2d5f481321@intel.com>
- User-agent: Evolution 3.44.4-0ubuntu2
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.
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]