Would it be possible to add seccomp support for m68k in the kernel?I just had another look at the topic and it seems with just need a minimal patch to add SECCOMP and SECCOMP_FILTER support when looking at the changes
There are some packages like kscreensaver in Debian that require libseccomp-dev and it would therefore be desirable if we could
that library on Linux/m68k as well.
From what I have learned from Helge Deller who added seccomp forhppa, it doesn't seem much that is necessary to get seccomp working
on an architecture.
So, if anyone could work on the kernel part, I could do the work on libseccomp.
[1] https://github.com/torvalds/linux/commit/5340627e3fe08030988bdda46dd86cd5d5fb7517
[2] https://github.com/seccomp/libseccomp/pull/271
Hello!
On 3/20/20 9:46 AM, John Paul Adrian Glaubitz wrote:
Would it be possible to add seccomp support for m68k in the kernel?I just had another look at the topic and it seems with just need a minimal patch to add SECCOMP and SECCOMP_FILTER support when looking at the changes for riscv64 [1].
There are some packages like kscreensaver in Debian that require
libseccomp-dev and it would therefore be desirable if we could
that library on Linux/m68k as well.
From what I have learned from Helge Deller who added seccomp forhppa, it doesn't seem much that is necessary to get seccomp working
on an architecture.
So, if anyone could work on the kernel part, I could do the work on
libseccomp.
The most complex change seem to be the changes in entry.S to add some additional
checks for syscall numbers. I think we could just do this for m68k (and SH) as
well.
The userland land part is trivial as well, I actually added SuperH support to libseccomp today which was rather easy but my pull request was rejected for the
time being due to SuperH not supporting SECCOMP_FILTER yet (only basic SECCOMP).
So, if someone could do the kernel pieces for m68k, I would work on the userspace
changes in libsseccomp.
Adrian
[1] https://github.com/torvalds/linux/commit/5340627e3fe08030988bdda46dd86cd5d5fb7517
[2] https://github.com/seccomp/libseccomp/pull/271
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -167,6 +167,8 @@ do_trace_entry:
jbsr syscall_trace_enter
RESTORE_SWITCH_STACK
addql #4,%sp
+ tstb %d0
+ jne ret_from_syscall
Looking at your SH patch, I see no changes to check for syscall numbers, just a check of the syscall_trace_enter() return code added? Is that all that's needed for m68k as well?
From my understanding, you basically check whether the syscall number is -1 and if that's the case, you just skip to ret_from_syscall. At least that's what we're doing on SH in entry.S.
What return code would we need to set on returning from an aborted syscall? (Without setting a specific one, -ENOSYS will be used by default.)
So, if someone could do the kernel pieces for m68k, I would work on the userspace
changes in libsseccomp.
My earlier patch switching m68k to use syscall_trace_enter() is incomplete, please add the return call check
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -167,6 +167,8 @@ do_trace_entry:
jbsr syscall_trace_enter
RESTORE_SWITCH_STACK
addql #4,%sp
+ tstb %d0
+ jne ret_from_syscall
movel %sp@(PT_OFF_ORIG_D0),%d0
cmpl #NR_syscalls,%d0
jcs syscall
On Jul 25 2020, Michael Schmitz wrote:
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -167,6 +167,8 @@ do_trace_entry:
jbsr syscall_trace_enter
RESTORE_SWITCH_STACK
addql #4,%sp
+ tstb %d0
+ jne ret_from_syscall
Why tstb and not tstl?
Andreas.
What return code would we need to set on returning from an aborted syscall? >> (Without setting a specific one, -ENOSYS will be used by default.)
If we're talking about syscall_trace_enter(), it should be -1.
Adrian
Andreas: could we preset -EPERM as return code on entering
do_trace_entry to save another jump, possibly even without setting
-ENOSYS before attempting the syscall, or would that break the syscall ABI?
No particular reason - I had seen testb used in the syscall entry code and
On Jul 26 2020, Michael Schmitz wrote:
OK, that's -EPERM. Reading the comment in asm/errno.h, -ENOSYS is not aENOSYS is the correct error number for unimplemented syscalls.
legitimate return code for syscalls to use.
Andreas.
On Jul 26 2020, Michael Schmitz wrote:
No particular reason - I had seen testb used in the syscall entry code andWhere? That may be bugs.
Andreas.
What I attempt to do is support syscall filtering. Returning -ENOSYS in
that case would run the risk of masking existing syscalls to user probe
code just because the user process happens to have insufficient privileges.
On Jul 27 2020, Michael Schmitz wrote:
Hi Andreas,How is that relevant? That is testing a single bit, of course.
On 26/07/20 11:03 PM, Andreas Schwab wrote:
On Jul 26 2020, Michael Schmitz wrote:Here:
No particular reason - I had seen testb used in the syscall entry code and >>> Where? That may be bugs.
ENTRY(ret_from_signal)
movel %curptr@(TASK_STACK),%a1
tstb %a1@(TINFO_FLAGS+2)
jge 1f
jbsr syscall_trace_leave
1: RESTORE_SWITCH_STACK
addql #4,%sp
....
and here:
ENTRY(system_call)
SAVE_ALL_SYS
GET_CURRENT(%d1)
movel %d1,%a1
| save top of frame
movel %sp,%curptr@(TASK_THREAD+THREAD_ESP0)
| syscall trace?
tstb %a1@(TINFO_FLAGS+2)
jmi do_trace_entry
cmpl #NR_syscalls,%d0
jcc badsys
Andreas.
On Jul 27 2020, Michael Schmitz wrote:
What I attempt to do is support syscall filtering. Returning -ENOSYS inWhat does ENOSYS have to do with privileges?
that case would run the risk of masking existing syscalls to user probe
code just because the user process happens to have insufficient privileges.
Andreas.
No, tstb tests a byte operand. btst tests a bit.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 292 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 206:49:27 |
| Calls: | 6,618 |
| Files: | 12,168 |
| Messages: | 5,316,894 |