On 01/20, Kees Cook wrote:

On Mon, Jan 20, 2025 at 02:44:52PM +0100, Oleg Nesterov wrote:

quoted

Depending on CONFIG_HAVE_ARCH_SECCOMP_FILTER, __secure_computing(NULL)
will crash or not, this is not consistent/safe.

Right now this never happens because there are no callers.

quoted

Fortunately, if CONFIG_HAVE_ARCH_SECCOMP_FILTER=n, __secure_computing()
has no callers, these architectures use secure_computing_strict().

As you say here.

quoted

Also, after the previous change __secure_computing(sd) is always called
with sd == NULL, so it is clear that we can remove the code which makes
no sense.

However, after this change, if someone were to *add* a caller, it would
bypass strict mode.

OK, thanks, I agree this is not consistent, even if I think that
!CONFIG_HAVE_ARCH_SECCOMP_FILTER arches should not add a new caller.

Instead of "return 0", it seems like it'd be better
to remove the function entirely (and maybe add a comment about calling
secure_computing_strict() directly)?

This means that __secure_computing() will be defined even if !CONFIG_SECCOMP,
but it won't be defined if CONFIG_SECCOMP && !CONFIG_HAVE_ARCH_SECCOMP_FILTER.

How about

	__secure_computing()
	{
		return secure_computing_strict(syscall_get_nr(...));
	}

in the "#ifndef CONFIG_HAVE_ARCH_SECCOMP_FILTER" section near
secure_computing_strict() in kernel/seccomp.c ?

Oleg.