From mboxrd@z Thu Jan 1 00:00:00 1970 From: takahiro.akashi@linaro.org (AKASHI Takahiro) Date: Thu, 10 Jul 2014 06:33:50 +0200 Subject: [RESEND PATCH v4 2/2] arm64: Add seccomp support In-Reply-To: <20140709111239.GH9485@arm.com> References: <1404459115-8292-1-git-send-email-takahiro.akashi@linaro.org> <1404459115-8292-3-git-send-email-takahiro.akashi@linaro.org> <20140709111239.GH9485@arm.com> Message-ID: <53BE17AE.7080301@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Will, > (1) Updating syscallno based on w8, but this ties us to the current ABI > and could get messy if this register changes in the future. So, is this the conclusion that I should follow? -Takahiro AKASHI On 07/09/2014 01:12 PM, Will Deacon wrote: > Hi Akashi, > > On Fri, Jul 04, 2014 at 08:31:55AM +0100, AKASHI Takahiro wrote: >> secure_computing() should always be called first in syscall_trace_enter(). >> If it returns non-zero, we should stop further handling. Then that system >> call may eventually fail, be trapped or the process itself be killed >> depending on loaded rules. >> In this case, syscall_trace_enter() returns a dedicated value in order to >> skip a normal syscall table lookup because a seccomp rule may have already >> overridden errno. > > [...] > >> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c >> index 70526cf..baab5fc 100644 >> --- a/arch/arm64/kernel/ptrace.c >> +++ b/arch/arm64/kernel/ptrace.c >> @@ -21,12 +21,14 @@ >> >> #include >> #include >> +#include >> #include >> #include >> #include >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -1109,6 +1111,10 @@ static void tracehook_report_syscall(struct pt_regs *regs, >> >> asmlinkage int syscall_trace_enter(struct pt_regs *regs) >> { >> + if (secure_computing(regs->syscallno) == -1) >> + /* seccomp failures shouldn't expose any additional code. */ >> + return -EPERM; >> + >> if (test_thread_flag(TIF_SYSCALL_TRACE)) >> tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER); > > We return regs->syscallno immediately after this, so we have the same issue > that Kees identified for arch/arm/. Did you follow the discussion I had with > Andy? > > Will >