Re: [QUESTION] powerpc, libseccomp, and spu
On Tue, Feb 12, 2019 at 9:50 AM Tom Hromatka wrote: > On 2/11/19 11:54 AM, Tom Hromatka wrote: > > PowerPC experts, > > > > Paul Moore and I are working on the v2.4 release of libseccomp, > > and as part of this work I need to update the syscall table for > > each architecture. > > > > I have incorporated the new ppc syscall.tbl into libseccomp, but > > I am not familiar with the value of "spu" in the ABI column. For > > example: > > > > 2232umountsys_oldumount > > 2264umountsys_ni_syscall > > 22spuumountsys_ni_syscall > > > > In libseccomp, we maintain a 32-bit ppc syscall table and a 64-bit > > ppc syscall table. Do we also need to add a "spu" ppc syscall > > table? Some clarification on the syscalls marked "spu" and "nospu" > > would be greatly appreciated. > > Thanks for the awesome responses, Ben and Michael. I'll definitely > get Paul's input as well, but it sounds reasonable to exclude SPUs > from the newest libseccomp release. Based on this thread, I don't think we need to worry about "spu" at this point in time. Thanks everyone. > Michael's recommendation to replace "nospu" with common" and ignore > "spu" entirely has allowed ppc and ppc64 to pass all of our internal > checks. > > Thanks again! > > Tom -- paul moore www.paul-moore.com
Re: [QUESTION] powerpc, libseccomp, and spu
On 2/11/19 11:54 AM, Tom Hromatka wrote: PowerPC experts, Paul Moore and I are working on the v2.4 release of libseccomp, and as part of this work I need to update the syscall table for each architecture. I have incorporated the new ppc syscall.tbl into libseccomp, but I am not familiar with the value of "spu" in the ABI column. For example: 22 32 umount sys_oldumount 22 64 umount sys_ni_syscall 22 spu umount sys_ni_syscall In libseccomp, we maintain a 32-bit ppc syscall table and a 64-bit ppc syscall table. Do we also need to add a "spu" ppc syscall table? Some clarification on the syscalls marked "spu" and "nospu" would be greatly appreciated. Thanks. Tom Thanks for the awesome responses, Ben and Michael. I'll definitely get Paul's input as well, but it sounds reasonable to exclude SPUs from the newest libseccomp release. Michael's recommendation to replace "nospu" with common" and ignore "spu" entirely has allowed ppc and ppc64 to pass all of our internal checks. Thanks again! Tom
Re: [QUESTION] powerpc, libseccomp, and spu
Hi Tom,
Sorry this has caused you trouble, using "spu" there is a bit of a hack
and I want to remove it.
See: https://patchwork.ozlabs.org/patch/1025830/
Unfortunately that series clashed with some of Arnd's work and I haven't
got around to rebasing it.
Tom Hromatka writes:
> PowerPC experts,
>
> Paul Moore and I are working on the v2.4 release of libseccomp,
> and as part of this work I need to update the syscall table for
> each architecture.
>
> I have incorporated the new ppc syscall.tbl into libseccomp, but
> I am not familiar with the value of "spu" in the ABI column. For
> example:
>
> 2232 umount sys_oldumount
> 2264 umount sys_ni_syscall
> 22spu umount sys_ni_syscall
>
> In libseccomp, we maintain a 32-bit ppc syscall table and a 64-bit
> ppc syscall table. Do we also need to add a "spu" ppc syscall
> table? Some clarification on the syscalls marked "spu" and "nospu"
> would be greatly appreciated.
The name "spu" comes from SPU, which are the small cores in the
Playstation 3. The value in the syscall table says whether that syscall
is available to SPU programs ("spu") or blocked ("nospu"). I don't think
you want to support libseccomp on SPUs, so basically you can just ignore
the spu/nospu distinction.
So I'm pretty sure you can just remove all the "spu" lines, and then
replace "nospu" with "common". As I've done below.
I'll try and get my patch above into a branch and into linux-next
somehow, so that you can at least refer to an upstream commit.
cheers
# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
#
# system call numbers and entry vectors for powerpc
#
# The format is:
#
#
# The can be common, 64, or 32 for this file.
#
0 common restart_syscall sys_restart_syscall
1 common exitsys_exit
2 common forkppc_fork
3 common readsys_read
4 common write sys_write
5 common opensys_open
compat_sys_open
6 common close sys_close
7 common waitpid sys_waitpid
8 common creat sys_creat
9 common linksys_link
10 common unlink sys_unlink
11 common execve sys_execve
compat_sys_execve
12 common chdir sys_chdir
13 common timesys_time
compat_sys_time
14 common mknod sys_mknod
15 common chmod sys_chmod
16 common lchown sys_lchown
17 common break sys_ni_syscall
18 32 oldstat sys_stat
sys_ni_syscall
18 64 oldstat sys_ni_syscall
19 common lseek sys_lseek
compat_sys_lseek
20 common getpid sys_getpid
21 common mount sys_mount
compat_sys_mount
22 32 umount sys_oldumount
22 64 umount sys_ni_syscall
23 common setuid sys_setuid
24 common getuid sys_getuid
25 common stime sys_stime
compat_sys_stime
26 common ptrace sys_ptrace
compat_sys_ptrace
27 common alarm sys_alarm
28 32 oldfstatsys_fstat
sys_ni_syscall
28 64 oldfstatsys_ni_syscall
29 common pause sys_pause
30 common utime sys_utime
compat_sys_utime
31 common sttysys_ni_syscall
32 common gttysys_ni_syscall
33 common access sys_access
34 common nicesys_nice
35 common ftime sys_ni_syscall
36 common syncsys_sync
37 common killsys_kill
38 common rename sys_rename
39 common mkdir sys_mkdir
40 common rmdir sys_rmdir
41 common dup sys_dup
42 common pipesys_pipe
43 common times sys_times
Re: [QUESTION] powerpc, libseccomp, and spu
On Mon, 2019-02-11 at 11:54 -0700, Tom Hromatka wrote: > PowerPC experts, > > Paul Moore and I are working on the v2.4 release of libseccomp, > and as part of this work I need to update the syscall table for > each architecture. > > I have incorporated the new ppc syscall.tbl into libseccomp, but > I am not familiar with the value of "spu" in the ABI column. For > example: > > 2232 umount sys_oldumount > 2264 umount sys_ni_syscall > 22spu umount sys_ni_syscall > > In libseccomp, we maintain a 32-bit ppc syscall table and a 64-bit > ppc syscall table. Do we also need to add a "spu" ppc syscall > table? Some clarification on the syscalls marked "spu" and "nospu" > would be greatly appreciated. On the Cell processor, there is a number of little co-processors (SPUs) that run alongside the main PowerPC core. Userspace can run code on them, they operate within the user context via their own MMUs. We provide a facility for them to issue syscalls (via some kind of RPC to the main core). The "SPU" indication indicates syscalls that can be called from the SPUs via that mechanism. Now, the big question is, anybody still using Cell ? :-) Cheers, Ben.
Re: [QUESTION] powerpc, libseccomp, and spu
On Mon, 2019-02-11 at 11:54 -0700, Tom Hromatka wrote: > PowerPC experts, > > Paul Moore and I are working on the v2.4 release of libseccomp, > and as part of this work I need to update the syscall table for > each architecture. > > I have incorporated the new ppc syscall.tbl into libseccomp, but > I am not familiar with the value of "spu" in the ABI column. For > example: > > 2232 umount sys_oldumount > 2264 umount sys_ni_syscall > 22spu umount sys_ni_syscall > > In libseccomp, we maintain a 32-bit ppc syscall table and a 64-bit > ppc syscall table. Do we also need to add a "spu" ppc syscall > table? Some clarification on the syscalls marked "spu" and "nospu" > would be greatly appreciated. On the Cell processor, there is a number of little co-processors (SPUs) that run alongside the main PowerPC core. Userspace can run code on them, they operate within the user context via their own MMUs. We provide a facility for them to issue syscalls (via some kind of RPC to the main core). The "SPU" indication indicates syscalls that can be called from the SPUs via that mechanism. Now, the big question is, anybody still using Cell ? :-) Cheers, Ben.
