[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXCcBBTzcL_yz3agNhby1huZSn2UGtJ9Soo=8n8_rj1Tg@mail.gmail.com>
Date: Fri, 9 Nov 2018 08:35:21 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Alexey Brodkin <alexey.brodkin@...opsys.com>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-audit@...hat.com,
Vineet Gupta <vineet.gupta1@...opsys.com>,
Eric Paris <eparis@...hat.com>,
"Dmitry V. Levin" <ldv@...linux.org>,
arcml <linux-snps-arc@...ts.infradead.org>,
Andrew Lutomirski <luto@...nel.org>,
Paul Moore <paul@...l-moore.com>,
Elvira Khabirova <lineprinter@...linux.org>
Subject: Re: [PATCH 06/13] arc: define syscall_get_arch()
On Fri, Nov 9, 2018 at 8:11 AM Alexey Brodkin
<alexey.brodkin@...opsys.com> wrote:
>
> Hi Andy,
>
> On Fri, 2018-11-09 at 07:56 -0800, Andy Lutomirski wrote:
> > > On Nov 9, 2018, at 7:27 AM, Alexey Brodkin <alexey.brodkin@...opsys.com> wrote:
> > >
> > > Hi Andy,
> > >
> > > > On Fri, 2018-11-09 at 07:17 -0800, Andy Lutomirski wrote:
> > > > On Fri, Nov 9, 2018 at 6:22 AM Alexey Brodkin
> > > > <alexey.brodkin@...opsys.com> wrote:
> > > > > Hi Dmitry,
> > > > >
> > > > > > On Fri, 2018-11-09 at 06:16 +0300, Dmitry V. Levin wrote:
> > > > > > syscall_get_arch() is required to be implemented on all architectures
> > > > > > that use tracehook_report_syscall_entry() in order to extend
> > > > > > the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
> > > > > >
> > > > > > Signed-off-by: Dmitry V. Levin <ldv@...linux.org>
> > > > > > ---
> > > > > > arch/arc/include/asm/syscall.h | 6 ++++++
> > > > > > include/uapi/linux/audit.h | 1 +
> > > > > > 2 files changed, 7 insertions(+)
> > > > >
> > > > > [snip]
> > > > >
> > > > > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > > > > > index 818ae690ab79..a7149ceb5b98 100644
> > > > > > --- a/include/uapi/linux/audit.h
> > > > > > +++ b/include/uapi/linux/audit.h
> > > > > > @@ -375,6 +375,7 @@ enum {
> > > > > >
> > > > > > #define AUDIT_ARCH_AARCH64 (EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> > > > > > #define AUDIT_ARCH_ALPHA (EM_ALPHA|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> > > > > > +#define AUDIT_ARCH_ARC (EM_ARC)
> > > > >
> > > > > Similarly here we need to have:
> > > > > ---------------------------->8-----------------------------
> > > > > +#define AUDIT_ARCH_ARC (EM_ARC|EM_ARCV2)
> > > > > ---------------------------->8-----------------------------
> > > > >
> > > >
> > > > Huh? How does the bitwise or of two ELF machine codes make any sense?
> > >
> > > Oops... I didn't read examples of AUDIT_ARCH_ALPHA above :(
> > > Indeed that was stupid.
> > >
> > > But what would be a proper fix then?
> > >
> > > Something like that?
> > > ---------------------------->8-----------------------------
> > > #define AUDIT_ARCH_ARC (EM_ARC)
> > > #define AUDIT_ARCH_ARCV2 (EM_ARCV2)
> > >
> > >
> > > static inline int syscall_get_arch(void)
> > > {
> > > #ifdef __ARC700__
> > > return AUDIT_ARCH_ARC;
> > > #else
> > > return AUDIT_ARCH_ARCV2;
> > > #endif
> > > }
> > > ---------------------------->8-----------------------------
> > >
> >
> > Maybe, but I know basically nothing about ARC. Is the syscall numbering or calling convention different on ARC vs ARCv2?
>
> Syscall numbering should be the same as we use UAPI for both ARCompact (AKA ARCv1)
> and ARCv2. As for calling convention I think it indeed differs.
>
> Note ARCompact and ARCv2 ISAs are binary incompatible!
>
> Even though assembly look pretty much the same (sans instructions
> available only for either ARCompact or ARCv2) encodings are different so
> in that sense these are completely different architectures.
>
> Also I'm wondering what could be other cases for use of syscall_get_arch().
The intent of syscall_get_arch() is that the tuple:
(arch, nr, arg1, ..., arg6)
fully identifies a system call and its arguments. So it sounds like
we do indeed need to arch values.
>
> So I'd say it's better to report different values for ARC ISAs.
> And given we use the same values as in Binutils IMHO it would be good
> to not mix IDs here.
>
> -Alexey
--
Andy Lutomirski
AMA Capital Management, LLC
Powered by blists - more mailing lists