linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org,
	pihsun@chromium.org
Subject: Re: [PATCH 1/3] arm64: compat: Avoid sending SIGILL for unallocated syscall numbers
Date: Fri, 4 Jan 2019 14:15:03 +0000	[thread overview]
Message-ID: <20190104141503.GD3571@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20190104134749.GA28158@edgewater-inn.cambridge.arm.com>

On Fri, Jan 04, 2019 at 01:47:49PM +0000, Will Deacon wrote:
> On Fri, Jan 04, 2019 at 12:54:26PM +0000, Dave Martin wrote:
> > On Thu, Jan 03, 2019 at 06:13:58PM +0000, Will Deacon wrote:
> > > The ARM Linux kernel handles the EABI syscall numbers as follows:
> > > 
> > >   0           - NR_SYSCALLS-1	: Invoke syscall via syscall table
> > >   NR_SYSCALLS - 0xeffff		: -ENOSYS (to be allocated in future)
> > >   0xf0000     - 0xf07ff		: Private syscall or -ENOSYS if not allocated
> > >   > 0xf07ff			: SIGILL
> > > 
> > > Our compat code gets this wrong and ends up sending SIGILL in response
> > > to all syscalls greater than NR_SYSCALLS which have a value greater
> > > than 0x7ff in the bottom 16 bits.
> > > 
> > > Fix this by defining the end of the ARM private syscall region and
> > > checking the syscall number against that directly. Update the comment
> > > while we're at it.
> > > 
> > > Cc: <stable@vger.kernel.org>
> > > Cc: Dave Martin <Dave.Martin@arm.com>
> > > Reported-by: Pi-Hsun Shih <pihsun@chromium.org>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > >  arch/arm64/include/asm/unistd.h | 5 +++--
> > >  arch/arm64/kernel/sys_compat.c  | 4 ++--
> > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
> > > index b13ca091f833..be66a54ee3a1 100644
> > > --- a/arch/arm64/include/asm/unistd.h
> > > +++ b/arch/arm64/include/asm/unistd.h
> > > @@ -40,8 +40,9 @@
> > >   * The following SVCs are ARM private.
> > >   */
> > >  #define __ARM_NR_COMPAT_BASE		0x0f0000
> > > -#define __ARM_NR_compat_cacheflush	(__ARM_NR_COMPAT_BASE+2)
> > > -#define __ARM_NR_compat_set_tls		(__ARM_NR_COMPAT_BASE+5)
> > > +#define __ARM_NR_compat_cacheflush	(__ARM_NR_COMPAT_BASE + 2)
> > > +#define __ARM_NR_compat_set_tls		(__ARM_NR_COMPAT_BASE + 5)
> > > +#define __ARM_NR_compat_syscall_end	(__ARM_NR_COMPAT_BASE + 0x800)
> > 
> > Nit: there is no compat_syscall_end().  Can we make this #define upper
> > case, like __ARM_NR_COMPAT_BASE, since a symbolic bound, not a syscall
> > number?
> 
> That's fair; I'll rename it to __ARM_NR_COMPAT_END.

Thanks

> 
> > >  #define __NR_compat_syscalls		399
> > >  #endif
> > > diff --git a/arch/arm64/kernel/sys_compat.c b/arch/arm64/kernel/sys_compat.c
> > > index 32653d156747..5972b7533fa0 100644
> > > --- a/arch/arm64/kernel/sys_compat.c
> > > +++ b/arch/arm64/kernel/sys_compat.c
> > > @@ -102,12 +102,12 @@ long compat_arm_syscall(struct pt_regs *regs)
> > >  
> > >  	default:
> > >  		/*
> > > -		 * Calls 9f00xx..9f07ff are defined to return -ENOSYS
> > > +		 * Calls 0xf0xxx..0xf07ff are defined to return -ENOSYS
> > >  		 * if not implemented, rather than raising SIGILL. This
> > >  		 * way the calling program can gracefully determine whether
> > >  		 * a feature is supported.
> > >  		 */
> > > -		if ((no & 0xffff) <= 0x7ff)
> > > +		if (no < __ARM_NR_compat_syscall_end)
> > 
> > arm_syscall() in arch/arm is not responsible for handling syscalls less
> > __ARM_NR_BASE; the code in entry-common.S redirects those directly to
> > sys_ni_syscall() instead.
> > 
> > Given how fiddly this is I think it's preferable if we keep to the
> > arch/arm code structure as much as possible, and call this function only
> > when no >= __ARM_NR_COMPAT_BASE?
> 
> I don't think we should be using the arm code structure as a template here.
> Although we're providing the same interface, we don't have to worry about
> things like OABI or ARM vs THUMB entry code. We're also in the process of
> moving more of this out of assembly and into C, so I'd rather keep the
> compat code as self-contained as possible.
> 
> Even if we did modify the caller so that we only call compat_arm_syscall()
> for numbers >= __ARM_NR_COMPAT_BASE, we'd still need the check above to
> handle numbers >= __ARM_NR_COMPAT_END, so I don't think we gain anything.

Well, I can live with it either way.

Cross-referencing the arm64 and arm trees for this functionality is
challenging, and will tend to get harder as the code diverges...  but
hopefully it's gone about as far as it's going to go by this point.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-04 14:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-03 18:13 [PATCH 0/3] Fix private compat syscall emulation Will Deacon
2019-01-03 18:13 ` [PATCH 1/3] arm64: compat: Avoid sending SIGILL for unallocated syscall numbers Will Deacon
2019-01-04  4:50   ` Sasha Levin
2019-01-04 12:54   ` Dave Martin
2019-01-04 13:47     ` Will Deacon
2019-01-04 14:15       ` Dave Martin [this message]
2019-01-03 18:13 ` [PATCH 2/3] arm64: compat: Don't pull syscall number from regs in arm_compat_syscall Will Deacon
2019-01-04  4:50   ` Sasha Levin
2019-01-04 12:37   ` Dave Martin
2019-01-03 18:14 ` [PATCH 3/3] arm64: compat: Hook up io_pgetevents() for 32-bit tasks Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190104141503.GD3571@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=pihsun@chromium.org \
    --cc=stable@vger.kernel.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).