Hi Geert,
On 26/08/20 11:23 PM, Geert Uytterhoeven wrote:
Hi Michael,
On Mon, Jul 27, 2020 at 6:19 AM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
m68k (other than Coldfire) uses syscall_trace for both trace entry
and trace exit. Seccomp support requires separate entry points for
trace entry and exit which are already provided for Coldfire.
Replace syscall_trace by syscall_trace_enter and syscall_trace_leave
in preparation for seccomp support. Check return code of
syscall_trace_enter(), and skip syscall if nonzero. Return code
will be left at what had been set by by ptrace or seccomp.
No regression seen in testing with strace on ARAnyM.
Signed-off-by: Michael Schmitz <schmitzmic@xxxxxxxxx>
Thanks for your patch!
Thanks for looking into it!
Changes from RFC v1:
- add return code check in do_trace_entry branch to enable syscall
filtering (will return -EPERM)
- change to use testl for return code check (suggested by Andreas Schwab)
Changes from RFC v2:
- don't set return code of filtered syscall - seccomp may want to set
that for use by calling process.
As your email subject didn't contain "v3", b4[*] insists on picking up
RFC v2, and refuses to pick up the latest version, even when forced
Argh - I thought that since the first two were tagged 'RFC', I could
just restart with v1.
Never heard of b4, sorry.
(msgid not present)...
The patch itself looks good to me. Does it make sense to apply it before
we have real seccomp support?
As far as I understand Adrian, it's needed as a prerequisite (though I
admit there needs to be another patch adding the actual seccomp bits as
well).
With my rather limited test setup, this was all I could test. I've done
enough damage with 'I think this is how it should work' patches to add
untested stuff.
In my not-at-all-humble opinion, the whole issue of whether to trigger a
syscall abort on any non-zero return code, or just -1, is quite academic
so I'd rather keep the broader non-zero test (unless someone points to a
clear-cut reason why this is a Bad Thing).
Cheers,
Michael
[*] https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
Gr{oetje,eeting}s,
Geert
