linux-kernel - Re: [PATCH 4/9] ARM: syscall: always store thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a0BZ-zdk+RB5ODcVs2z-Y6xmLCp57uzivUGWRcoeH2fQQ@mail.gmail.com>
Date:   Mon, 28 Sep 2020 14:42:43 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Christoph Hellwig <hch@....de>,
        Russell King <rmk@....linux.org.uk>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        "linux-kernel@...r.kernel.org" <kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Russell King <linux@...linux.org.uk>,
        Oleg Nesterov <oleg@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/9] ARM: syscall: always store thread_info->syscall

On Mon, Sep 28, 2020 at 11:41 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> Hi Arnd,
>
> help me out here because I feel vaguely stupid...
>
> On Mon, Sep 7, 2020 at 5:38 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> >  {
> > +       if (IS_ENABLED(CONFIG_OABI_COMPAT))
> > +               return task_thread_info(task)->syscall & ~__NR_OABI_SYSCALL_BASE;
>
> Where __NR_OABI_SYSCALL_BASE is
> #define __NR_OABI_SYSCALL_BASE       0x900000
>
> So you will end up with sycall number & FF6FFFFF
> masking off bits 20 and 23.

Right. I fixed a bug in here since I sent this, the correct version also
needs to mask away the __NR_OABI_SYSCALL_BASE for a native
oabi kernel, not just for an eabi kernel with oabi-compat mode.

> I suppose this is based on this:
>
> >         bics    r10, r10, #0xff000000
> > +       str     r10, [tsk, #TI_SYSCALL]
>
> OK we mask off bits 24-31 before we store this.
>
> >         bic     scno, scno, #0xff000000         @ mask off SWI op-code
> > +       str     scno, [tsk, #TI_SYSCALL]
>
> And here too.
>
> >         eor     scno, scno, #__NR_SYSCALL_BASE  @ check OS number
>
> And then happens that which will ... I don't know really.
> Exclusive or with 0x9000000 is not immediately intuitive
> evident to me, I suppose it is for everyone else... :/

This is how the SWI/SVC immediate argument gets turned into
a system call number that is used as an offset into the sys_call_table.

OABI syscalls are called with '__NR_OABI_SYSCALL_BASE | scno'
in the immediate argument of the instruction, so using an
'eor ... , #__NR_SYSCALL_BASE' means that any valid
argument afterwards is a number between zero and
__NR_syscalls, and any invalid argument is a number outside
of that range

EABI syscalls are just 'SVC 0' with the syscall number in register 7
and no offset.

See also
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f2829a31573e3e502b874c8d69a765f7a778793

> I need some idea how this numberspace is managed in order to
> understand the code so I can review it, I guess it all makes perfect
> sense but I need some background here.

I also had never understood this part before, and I'm still not
sure where the 0x900000 actually comes from, though my best
guess is that this was intended as a an OS specific number space,
with '9' being assigned to Linux (similar to the way Itanium and
MIPS do with their respective offsets). By the time EABI got added,
this was apparently no longer considered helpful.

        Arnd