From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 56C17C43602 for ; Wed, 8 Jul 2026 01:44:08 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4gw1924wSpz2yft; Wed, 08 Jul 2026 11:44:06 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=113.46.200.222 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1783475046; cv=none; b=Z0Z4A8CS7VkcuvbSqz35eGKnzefxHI5EaktwsmOOOcPEXpR0KubfP+QLoKk/p8PMl61dNewxbw/jz3kDQjmf5wNt2ERs5AVVIkwrE65tsI/dR8W+EpmNYJ2hRdpjOn8jgVPJ9iEmv1oMZd0o3+mCZx7wFpnZnOWJtFmGgOt7OSBumt9akKFesrkgfuKZM80q4xd6poz/Yjn0i/QdFNxJQXMISTUsrD8ybyoKe+H1Sy26InMGjGlrErJ0czmF6KG9MAehbgG0GrNdqj6BNob+xwFrS6h341HicLzRGSlmnK7YittEyBN2Xm3PmFTqPUNtzVH2aZ8+NplbXglKaOXaPw== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1783475046; c=relaxed/relaxed; bh=PdZvJupbHpc2hOYnTOWKrk/la+Cgt9ShW3j2lWe0WJs=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=abDn8fgedLw2TYPjTuVq0K1ItyzCtRyZovF37obvLJosxZh83ixPcjTfFyMbmY5bwp7PPft80U3y4UJT/h4tZt25w2Q1OkoKaT4DX0ATOctAz1sX3EkXOi3D+GsYHvovuXYlQgeIse3cpfOmJUFtNV/Jaj5H5sgFPhTWYuQo0EJY9ZOElbEnJGFh7VV/FcZ4wGWO9O+jYe+GcB4Jp80O5z0dxp4xX0AXBuFfR/I0QkpFZ4S9Qhe0uPlmyZuhTlAYpnprgm38VBgrwWZwrB4FdLNRJ0+m2/7v5FcI+UlaX3BRju+DkHhAQjbP5d6/pCABeEkSHZh1iAqGEsvNwAMbxQ== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; dkim=pass (1024-bit key; unprotected) header.d=huawei.com header.i=@huawei.com header.a=rsa-sha256 header.s=dkim header.b=5hA9y/nb; dkim-atps=neutral; spf=pass (client-ip=113.46.200.222; helo=canpmsgout07.his.huawei.com; envelope-from=ruanjinjie@huawei.com; receiver=lists.ozlabs.org) smtp.mailfrom=huawei.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=huawei.com header.i=@huawei.com header.a=rsa-sha256 header.s=dkim header.b=5hA9y/nb; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=113.46.200.222; helo=canpmsgout07.his.huawei.com; envelope-from=ruanjinjie@huawei.com; receiver=lists.ozlabs.org) Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4gw19024KZz2xm3 for ; Wed, 08 Jul 2026 11:44:01 +1000 (AEST) dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=PdZvJupbHpc2hOYnTOWKrk/la+Cgt9ShW3j2lWe0WJs=; b=5hA9y/nbJT2Rdg9agSG6EdreDMBgYhixnmJvdWlfr8XidFnsSzCZu1Z1RT4/0VWszYj3O4mq/ EgOdnVoPIUBGLqZev43itv9gO4V5NDlaHCFpwiBMuwwoePes9JuQ/NhfwH1VMdkJPUaHTUdzc7M av1A0vhQhzopjwvWZCaC8Vk= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4gw0y549jNzLlTw; Wed, 8 Jul 2026 09:34:37 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 665034057C; Wed, 8 Jul 2026 09:43:51 +0800 (CST) Received: from [10.67.109.254] (10.67.109.254) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 8 Jul 2026 09:43:48 +0800 Message-ID: <2e6ed364-ce8f-4b4b-8675-acd07f140f4f@huawei.com> Date: Wed, 8 Jul 2026 09:43:46 +0800 X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [patch 11/18] seccomp, treewide: Rename and convert __secure_computing() to return boolean To: Thomas Gleixner , LKML CC: Peter Zijlstra , Mark Rutland , Kees Cook , Andy Lutomirski , Oleg Nesterov , Richard Henderson , Russell King , Catalin Marinas , Guo Ren , Geert Uytterhoeven , Thomas Bogendoerfer , Helge Deller , Yoshinori Sato , Richard Weinberger , Chris Zankel , , , , , , , , , Michael Ellerman , Shrikanth Hegde , , Huacai Chen , , Paul Walmsley , Palmer Dabbelt , , Sven Schnelle , , , Arnd Bergmann , Vineet Gupta , Will Deacon , Brian Cain , Michal Simek , Dinh Nguyen , "David S. Miller" , Andreas Larsson , , , , , , =?UTF-8?Q?Michal_Such=C3=A1nek?= , Jonathan Corbet , References: <20260707181957.433213175@kernel.org> <20260707190254.230735780@kernel.org> From: Jinjie Ruan In-Reply-To: <20260707190254.230735780@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.109.254] X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To dggpemf500011.china.huawei.com (7.185.36.131) On 7/8/2026 3:06 AM, Thomas Gleixner wrote: > From: Jinjie Ruan > > The return value of __secure_computing() currently uses 0 to indicate > that a system call should be allowed, and -1 to indicate that it should > be blocked/killed. This 0/-1 pattern is non-intuitive for a security > check function and makes the control flow at the call sites less readable. > > Furthermore, any potential future changes to these return values would > require a high-risk, error-prone audit of all its users across different > architectures. > > Sanitize this logic by converting the return type of __secure_computing() > to a proper boolean, where 'true' explicitly means 'allow' and 'false' > means 'fail/deny'. > > Update all the two dozen or so call sites across the tree to align with > this new boolean semantic. No functional changes are intended, as the > callers still return -1 to the lower-level assembly entry code upon > seccomp denial. > > Rename the function to __seccomp_permit_syscall() so that the purpose is > entirely clear. > > [ tglx: Rename the function ] > > Suggested-by: Thomas Gleixner > Suggested-by: Mark Rutland > Signed-off-by: Jinjie Ruan > Signed-off-by: Thomas Gleixner > Cc: Kees Cook > Cc: Andy Lutomirski > Cc: Oleg Nesterov > Cc: Richard Henderson > Cc: Russell King > Cc: Catalin Marinas > Cc: Guo Ren > Cc: Geert Uytterhoeven > Cc: Thomas Bogendoerfer > Cc: Helge Deller > Cc: Yoshinori Sato > Cc: Richard Weinberger > Cc: Chris Zankel > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-alpha@vger.kernel.org > Cc: linux-csky@vger.kernel.org > Cc: linux-m68k@lists.linux-m68k.org > Cc: linux-mips@vger.kernel.org > Cc: linux-parisc@vger.kernel.org > Cc: linux-sh@vger.kernel.org > Cc: linux-um@lists.infradead.org > --- > arch/alpha/kernel/ptrace.c | 2 - > arch/arm/kernel/ptrace.c | 2 - > arch/arm64/kernel/ptrace.c | 2 - > arch/csky/kernel/ptrace.c | 2 - > arch/m68k/kernel/ptrace.c | 2 - > arch/mips/kernel/ptrace.c | 2 - > arch/parisc/kernel/ptrace.c | 2 - > arch/sh/kernel/ptrace_32.c | 2 - > arch/um/kernel/skas/syscall.c | 2 - > arch/x86/entry/vsyscall/vsyscall_64.c | 14 ++++++------- > arch/xtensa/kernel/ptrace.c | 3 -- > include/linux/entry-common.h | 9 +++----- > include/linux/seccomp.h | 12 +++++------ > kernel/seccomp.c | 35 +++++++++++++++++----------------- > 14 files changed, 45 insertions(+), 46 deletions(-) As Ada pointed out, the description of secure_computing in arch/Kconfig need to be updated, a possible suggestion: --- a/arch/Kconfig +++ b/arch/Kconfig @@ -636,8 +636,8 @@ config HAVE_ARCH_SECCOMP_FILTER - syscall_rollback() - syscall_set_return_value() - SIGSYS siginfo_t support - - secure_computing is called from a ptrace_event()-safe context - - secure_computing return value is checked and a return value of -1 + - seccomp_permits_syscall is called from a ptrace_event()-safe context + - seccomp_permits_syscall return value is checked and if false Link: https://lore.kernel.org/all/b8f3b5cd-8d8a-4396-ba0c-011a83234dd9@arm.com/ > --- a/arch/alpha/kernel/ptrace.c > +++ b/arch/alpha/kernel/ptrace.c > @@ -387,7 +387,7 @@ asmlinkage unsigned long syscall_trace_e > * If this fails, seccomp may already have set up the return value > * (e.g. SECCOMP_RET_ERRNO / TRACE). > */ > - if (secure_computing() == -1) { > + if (!seccomp_permit_syscall()) { > if (regs->r19 == 0 && regs->r0 == (unsigned long)-1) > syscall_set_return_value(current, regs, -ENOSYS, 0); > syscall_set_nr(current, regs, -1); [...] > -static int __seccomp_filter(int this_syscall, const bool recheck_after_trace) > +static bool __seccomp_filter(int this_syscall, const bool recheck_after_trace) > { > u32 filter_ret, action; > struct seccomp_data sd; > @@ -1294,7 +1295,7 @@ static int __seccomp_filter(int this_sys > case SECCOMP_RET_TRACE: > /* We've been put in this state by the ptracer already. */ > if (recheck_after_trace) > - return 0; > + return true; > > /* ENOSYS these calls if there is no tracer attached. */ > if (!ptrace_event_enabled(current, PTRACE_EVENT_SECCOMP)) { > @@ -1330,19 +1331,19 @@ static int __seccomp_filter(int this_sys > * a skip would have already been reported. > */ > if (__seccomp_filter(this_syscall, true)) > - return -1; > + return false; The return value of __seccomp_filter is checked in the wrong way, check -1 should be replaced with check false, maybe: - if (__seccomp_filter(this_syscall, true)) - return -1; + if (!__seccomp_filter(this_syscall, true)) + return false; otherwise, LGTM Reviewed-by: Jinjie Ruan > > - return 0; > + return true; > > case SECCOMP_RET_USER_NOTIF: > if (seccomp_do_user_notification(this_syscall, match, &sd)) > goto skip; > > - return 0; > + return true; > > case SECCOMP_RET_LOG: > seccomp_log(this_syscall, 0, action, true); > - return 0; > + return true; > > case SECCOMP_RET_ALLOW: > /* > @@ -1350,7 +1351,7 @@ static int __seccomp_filter(int this_sys > * this action since SECCOMP_RET_ALLOW is the starting > * state in seccomp_run_filters(). > */ > - return 0; > + return true; > > case SECCOMP_RET_KILL_THREAD: > case SECCOMP_RET_KILL_PROCESS: > @@ -1367,46 +1368,46 @@ static int __seccomp_filter(int this_sys > } else { > do_exit(SIGSYS); > } > - return -1; /* skip the syscall go directly to signal handling */ > + return false; /* skip the syscall go directly to signal handling */ > } > > unreachable(); > > skip: > seccomp_log(this_syscall, 0, action, match ? match->log : false); > - return -1; > + return false; > } > #else > -static int __seccomp_filter(int this_syscall, const bool recheck_after_trace) > +static bool __seccomp_filter(int this_syscall, const bool recheck_after_trace) > { > BUG(); > > - return -1; > + return false; > } > #endif > > -int __secure_computing(void) > +bool __seccomp_permit_syscall(void) > { > int mode = current->seccomp.mode; > int this_syscall; > > if (IS_ENABLED(CONFIG_CHECKPOINT_RESTORE) && > unlikely(current->ptrace & PT_SUSPEND_SECCOMP)) > - return 0; > + return true; > > this_syscall = syscall_get_nr(current, current_pt_regs()); > > switch (mode) { > case SECCOMP_MODE_STRICT: > __secure_computing_strict(this_syscall); /* may call do_exit */ > - return 0; > + return true; > case SECCOMP_MODE_FILTER: > return __seccomp_filter(this_syscall, false); > /* Surviving SECCOMP_RET_KILL_* must be proactively impossible. */ > case SECCOMP_MODE_DEAD: > WARN_ON_ONCE(1); > do_exit(SIGKILL); > - return -1; > + return false; > default: > BUG(); > } >