Re: [PATCH 2/3] ARM: convert to generated system call tables

Re: [PATCH 2/3] ARM: convert to generated system call tables

[Michael Cree]

On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> I see your point, but I think there are serious issues with the current
> approach as well:
> 
> - a lot of the less common architectures just don't get updated
>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> 
> - some architectures that add all syscalls sometimes make a mistake
>   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>   did add the later __NR_execveat.

__NR_bpf was not forgotten on Alpha.  It was not wired up because
extra architecture support is needed which has not been implemented.

But maybe we should just wire it up to sys_ni_syscall in the meantime
so a syscall number is reserved for it, and user space can call it to
get -ENOSYS returned.

Cheers
Michael.

Re: [PATCH 2/3] ARM: convert to generated system call tables

[Arnd Bergmann]

On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > I see your point, but I think there are serious issues with the current
> > approach as well:
> > 
> > - a lot of the less common architectures just don't get updated
> >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > 
> > - some architectures that add all syscalls sometimes make a mistake
> >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> >   did add the later __NR_execveat.
> 
> __NR_bpf was not forgotten on Alpha.  It was not wired up because
> extra architecture support is needed which has not been implemented.
> 
> But maybe we should just wire it up to sys_ni_syscall in the meantime
> so a syscall number is reserved for it, and user space can call it to
> get -ENOSYS returned.

Ah, I must have misinterpreted the code then. I assumed that the
bpf syscall always works on all architectures, but that only the
jit compiler for it required architecture specific code to make it
more efficient.

The implementation of sys_bfp is compile-time selectable at the moment
and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
If it doesn't work on Alpha, maybe that symbol could have a "depends
on !ALPHA" or "depends on BPF_SUPPORT"?

sys_seccomp is another one that falls into a similar category, but
it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
architectures have assigned a syscall number but not set this symbol.
This one will actually allow you to set strict seccomp mode even
without the Kconfig symbol, just not allow to set a filter.

	Arnd

Re: [PATCH 2/3] ARM: convert to generated system call tables

[Richard Henderson]

On 10/25/2016 03:28 AM, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>>> I see your point, but I think there are serious issues with the current
>>> approach as well:
>>>
>>> - a lot of the less common architectures just don't get updated
>>>   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>>>   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>>>
>>> - some architectures that add all syscalls sometimes make a mistake
>>>   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>>>   did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha.  It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
> 
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.

That was my interpretation as well.  What's the problem, Michael?


r~

Re: [PATCH 2/3] ARM: convert to generated system call tables

[Geert Uytterhoeven]

On Tue, Oct 25, 2016 at 12:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
>> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>> > I see your point, but I think there are serious issues with the current
>> > approach as well:
>> >
>> > - a lot of the less common architectures just don't get updated
>> >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
>> >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
>> >
>> > - some architectures that add all syscalls sometimes make a mistake
>> >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
>> >   did add the later __NR_execveat.
>>
>> __NR_bpf was not forgotten on Alpha.  It was not wired up because
>> extra architecture support is needed which has not been implemented.
>>
>> But maybe we should just wire it up to sys_ni_syscall in the meantime
>> so a syscall number is reserved for it, and user space can call it to
>> get -ENOSYS returned.
>
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.
>
> The implementation of sys_bfp is compile-time selectable at the moment
> and falls back to sys_no_syscall if CONFIG_BPF_SYSCALL is disabled.
> If it doesn't work on Alpha, maybe that symbol could have a "depends
> on !ALPHA" or "depends on BPF_SUPPORT"?

Yes, BPF should just work (m68k has it).

> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.

Seccomp needs architecture support (m68k doesn't have it).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/3] ARM: convert to generated system call tables

[Michael Cree]

On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > I see your point, but I think there are serious issues with the current
> > > approach as well:
> > > 
> > > - a lot of the less common architectures just don't get updated
> > >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > 
> > > - some architectures that add all syscalls sometimes make a mistake
> > >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > >   did add the later __NR_execveat.
> > 
> > __NR_bpf was not forgotten on Alpha.  It was not wired up because
> > extra architecture support is needed which has not been implemented.
> > 
> > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > so a syscall number is reserved for it, and user space can call it to
> > get -ENOSYS returned.
> 
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.

Oh.  When someone posted wiring up of syscalls on Alpha some time
back I raised a query about seccomp then someone else (I can't be
bothered looking up the old emails, it doesn't really matter)
said bpf was in the same basket, so the patch was re-submitted with
neither of those syscalls.

> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.

We have got way behind on syscalls on Alpha and I was just in the
process of wiring them up and testing them, so I will include both
seccomp and bpf in that.

Cheers
Michael.

bpf on Alpha [was Re: [PATCH 2/3] ARM: convert to generated system call tables]

[Michael Cree]

On Wed, Oct 26, 2016 at 08:04:30PM +1300, Michael Cree wrote:
> On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > > I see your point, but I think there are serious issues with the current
> > > > approach as well:
> > > > 
> > > > - a lot of the less common architectures just don't get updated
> > > >   in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > >   only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > > 
> > > > - some architectures that add all syscalls sometimes make a mistake
> > > >   and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > >   did add the later __NR_execveat.
> > > 
> > > __NR_bpf was not forgotten on Alpha.  It was not wired up because
> > > extra architecture support is needed which has not been implemented.
> > > 
> > > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > > so a syscall number is reserved for it, and user space can call it to
> > > get -ENOSYS returned.
> > 
> > Ah, I must have misinterpreted the code then. I assumed that the
> > bpf syscall always works on all architectures, but that only the
> > jit compiler for it required architecture specific code to make it
> > more efficient.
> 
> Oh.  When someone posted wiring up of syscalls on Alpha some time
> back I raised a query about seccomp then someone else (I can't be
> bothered looking up the old emails, it doesn't really matter)
> said bpf was in the same basket, so the patch was re-submitted with
> neither of those syscalls.
> 
> > sys_seccomp is another one that falls into a similar category, but
> > it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> > architectures have assigned a syscall number but not set this symbol.
> > This one will actually allow you to set strict seccomp mode even
> > without the Kconfig symbol, just not allow to set a filter.
> 
> We have got way behind on syscalls on Alpha and I was just in the
> process of wiring them up and testing them, so I will include both
> seccomp and bpf in that.

Having just wired up bpf on an Alpha and run samples/bpf/test_verifier
I get:

#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK

[snip many passing tests]

#69 unpriv: check that printk is disallowed FAIL
failed to load prog 'Invalid argument'
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r1 = r10
2: (07) r1 += -8
3: (b7) r2 = 8
4: (bf) r3 = r1
5: (85) call 6
unknown func 6

[snip many more passing tests]

Summary: 101 PASSED, 1 FAILED

Should I be concerned about the failing #69 test?

Cheers
Michael.