linux-kernel - Re: [PATCH 2/4] seccomp: kill the dead code in the !CONFIG_HAVE_ARCH_SECCOMP_FILTER version of __secure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250121143038.GB3422@redhat.com>
Date: Tue, 21 Jan 2025 15:30:39 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Kees Cook <kees@...nel.org>
Cc: Andy Lutomirski <luto@...capital.net>, Will Drewry <wad@...omium.org>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Madhavan Srinivasan <maddy@...ux.ibm.com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org,
	linux-mips@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 2/4] seccomp: kill the dead code in the
 !CONFIG_HAVE_ARCH_SECCOMP_FILTER version of __secure_computing()

On 01/20, Kees Cook wrote:
>
> On Mon, Jan 20, 2025 at 02:44:52PM +0100, Oleg Nesterov wrote:
> > 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.
>
> > Fortunately, if CONFIG_HAVE_ARCH_SECCOMP_FILTER=n, __secure_computing()
> > has no callers, these architectures use secure_computing_strict().
>
> As you say here.
>
> > 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.