From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FB812F8EBA for ; Thu, 25 Jun 2026 11:34:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782387249; cv=none; b=CzGaLZtDp2UKKguZJ2yRi7xLH7pt78iVZTbztNg74Nd9GWXDOcnEilKYNtHuHoOsbilnR+JyekTGxii3HFjfJcSgjMGxK9HBhdrVHNqj7g6xSTBQno7FIem6FA2HfziafJ59nQhVpf6+TSpmBK3/2sN09FvSGn70nHPfPcbxfxk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782387249; c=relaxed/simple; bh=oVnA6drMkZBVVtK7FJYm6gtZL3NSrcSDKlZ6D9FfwSA=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=R0E3Au/PKO5VpzSGd8cK5tZDYRyPMGeWsK/PWmHO+hKs/yWA0iamyc9bxM6Gz+SRUAuem4/xV5M4M8dw+NTalXtFeDmkL+KNWjgk9HQOzu4ZLkgF0BWBVlouhOPlik5lYV4MxCVub12gxn3PdYVphtPt7Dtf8TOjtc0qdUPmYVs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Wy1k/cLA; arc=none smtp.client-ip=113.46.200.224 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Wy1k/cLA" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=fXOz4jKArAa5FB5VMTHkpC4nEe2uwAH6zF/L/3EeZfM=; b=Wy1k/cLAWGE8qt89xVYj/vj1klZ2id/bD2hcZLA25m73R8VhSw2DkzXuQ8XmFegOU7U2KJUq+ JTHz9Ow0aQnVjsxXvfpODtQiyPVfwezSoT6CB1rdWTQxNw3UN27cnS4T9rqhSZUxw6+qdPV02Xx X/5juMsJsgRy3IiCrn0GHTw= Received: from mail.maildlp.com (unknown [172.19.163.163]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4gmGg75CxKz1cyT1; Thu, 25 Jun 2026 19:24:51 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 51FE640575; Thu, 25 Jun 2026 19:33:56 +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; Thu, 25 Jun 2026 19:33:54 +0800 Message-ID: <67c3ae5c-d88b-4172-9996-4e2046b7e0dc@huawei.com> Date: Thu, 25 Jun 2026 19:33:53 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 01/11] entry: Fix potential syscall truncation in syscall_trace_enter() To: Thomas Gleixner , , , , , , , , , , , , , , , , , , , , , , , References: <20260511092103.1974980-1-ruanjinjie@huawei.com> <20260511092103.1974980-2-ruanjinjie@huawei.com> <874iirlu50.ffs@fw13> From: Jinjie Ruan In-Reply-To: <874iirlu50.ffs@fw13> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To dggpemf500011.china.huawei.com (7.185.36.131) On 6/25/2026 1:34 AM, Thomas Gleixner wrote: > On Mon, May 11 2026 at 17:20, Jinjie Ruan wrote: >> In syscall_trace_enter(), the current logic returns "ret ? : syscall". >> While __secure_computing() currently only returns 0 (allow) or -1 (kill), >> this "ret ? : syscall" pattern is conceptually flawed. >> >> If __secure_computing() were to return a non-zero value that isn't -1, it >> would unintentionally override the actual system call number. This logic >> is redundant because if seccomp denies the syscall, the execution path >> should already be handled by the caller based on the error return, rather >> than conflating the return code with the syscall number. >> >> Fix it by explicitly returning the syscall number. This ensures >> the syscall register remains untainted by the trace return values and >> aligns with the expectation that seccomp-related interceptions are >> handled via the -1 return status. >> >> Cc: Thomas Gleixner >> Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality") > > What's fixed here? > > A potential future change of the __secure_computing() return value > requires that _ALL_ callsites of that function have to be audited > and fixed up, no? > > So the change is not a fix it's an optimization to get rid of the extra > conditional. > > If you really want to sanitize this, then change the > __secure_computing() return type to boolean (true = allow, false = > fail) and fixup the two dozen or so call sites. Hi, Thomas That's an excellent suggestion. Changing __secure_computing() to a boolean return type makes the seccomp boundary much more intuitive and cleans up a lot of historical legacy. I am happy to take this on. I will implement this sanitization by changing the return type to bool and fixing up all the ~24 call sites across the tree. To keep the series clean and bisectable, I will include this as a standalone prerequisite cleanup patch at the very beginning of the v16 series. Thanks for pushing for a cleaner codebase! Best regards, Jinjie > > Thanks, > > tglx >