On Tue, Oct 30, 2018 at 10:21 AM, Tycho Andersen [off-list ref] wrote:

On Tue, Oct 30, 2018 at 05:39:26PM +0100, Oleg Nesterov wrote:

quoted

On 10/30, Oleg Nesterov wrote:

quoted

On 10/30, Tycho Andersen wrote:

quoted

@@ -828,6 +823,11 @@ static int __seccomp_filter(int this_syscall, const struct seccomp_data *sd,
   */
  rmb();

+ if (!sd) {
+         populate_seccomp_data(&sd_local);
+         sd = &sd_local;
+ }
+

To me it would be more clean to remove the "if (!sd)" check, case(SECCOMP_RET_TRACE)
in __seccomp_filter() can simply do populate_seccomp_data(&sd_local) unconditionally
and pass &sd_local to __seccomp_filter().

Ah, please ignore, emulate_vsyscall() does secure_computing(NULL).

Right.

quoted

Btw. why __seccomp_filter() doesn't return a boolean?

Because it was wrapped by __secure_computing(). *shrug* The common
method in the kernel is to use int and 0=ok.

quoted

Or at least, why can't case(SECCOMP_RET_TRACE) simply do

      return __seccomp_filter(this_syscall, NULL, true);

?

Yeah, at least the second one definitely makes sense. I can add that
as a patch in the next version of this series unless Kees does it
before.

I'd like to avoid changing the return value of __secure_computing() to
just avoid having to touch all the callers. And I'd prefer not to
change __seccomp_filter() to a bool, since I'd like the return values
to be consistent through the call chain.

I find the existing code more readable than a single-line return, just
because it's very explicit. I don't want to have to think any harder
when reading seccomp. ;)

-Kees

-- 
Kees Cook