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 compat_sys_time
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.