Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1594314pxk; Fri, 4 Sep 2020 13:33:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzIbOxqIAaTwjFzSMZjr95TIo2RhaAe7D5zmw/4KxyCWSXt9Wp3mPo9AEEZtOa4+UzZpqzt X-Received: by 2002:a17:906:4b41:: with SMTP id j1mr9079884ejv.1.1599251610646; Fri, 04 Sep 2020 13:33:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599251610; cv=none; d=google.com; s=arc-20160816; b=erFc31D0dss/LqiVNqMDxl0K6B2QNifQ7s16P/BBHHQngVMg4lNNX1kSkP6c/Ag5CM 609NH825bf2tjVxpVwf+MiJvM6S2lUikY4nKxS2yB8J6vJ245S4H4Hq0PczZOFjK5uOk uGlchT3tn43O33J2RBMK73PKcuVfSf2pl/4dqSh1j6Y89VzOL1lzY2Nub1jGTFpIWlQU GitsKNFqROXU7uheNlIslD2Sw91SUlmsF0fiiMGYSm7QR3LDdYDDo5t78rvHLSyugcqt y41b7Ybprj7uGdhsMzbZ+NtDJImDFW+mPQr1Sgde5d70zvjHOds8uJpRWKCAhiwfOZSl 6cLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=rfKD0fB2D7u5kUvU1nyur6OtnxvNPzE6vDwRlnrEQ1w=; b=bjnkuc5LJfR/NT+LPZjUtAbI0gzYTb7iAtw1MyY43dRDp7vfvp7/sp2RWu5qxv069w EkE+I3MuO3A1kjLXC9M1Ku06etCIuC0ZX0YyKCVH0XPx19LQOSTHbzflXyy9vgDb5KX+ 27zySR8mQTkHl9vSpRVQXN8ZVBI7ysDortNcJXZ3oy9kVWS/3LJrSuD0YsoPQaJHUgwA b6MN8z7o1lsCn2jYu8oekbAUIfuvl0RL231cp9KqjpVUuBlR9yeRHP9ujGeILPyN93z5 vGjPt4UV40zpKta4GqIs4Gdg8rjk0KUdnHjudInt5JoZ9j3kdLkJGQqYBYFbl1Sk4qyN slKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w6si1320358edl.52.2020.09.04.13.33.08; Fri, 04 Sep 2020 13:33:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728183AbgIDUcT (ORCPT + 99 others); Fri, 4 Sep 2020 16:32:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726621AbgIDUcR (ORCPT ); Fri, 4 Sep 2020 16:32:17 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BABD6C061244; Fri, 4 Sep 2020 13:32:16 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 6224429B031 From: Gabriel Krisman Bertazi To: luto@kernel.org, tglx@linutronix.de, keescook@chromium.org Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, willy@infradead.org, linux-kselftest@vger.kernel.org, shuah@kernel.org, Gabriel Krisman Bertazi , kernel@collabora.com Subject: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry Date: Fri, 4 Sep 2020 16:31:44 -0400 Message-Id: <20200904203147.2908430-7-krisman@collabora.com> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904203147.2908430-1-krisman@collabora.com> References: <20200904203147.2908430-1-krisman@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Syscall User Dispatch (SUD) must take precedence over seccomp, since the use case is emulation (it can be invoked with a different ABI) such that seccomp filtering by syscall number doesn't make sense in the first place. In addition, either the syscall is dispatched back to userspace, in which case there is no resource for seccomp to protect, or the syscall will be executed, and seccomp will execute next. Regarding ptrace, I experimented with before and after, and while the same ABI argument applies, I felt it was easier to debug if I let ptrace happen for syscalls that are dispatched back to userspace. In addition, doing it after ptrace makes the code in syscall_exit_work slightly simpler, since it doesn't require special handling for this feature. Signed-off-by: Gabriel Krisman Bertazi --- kernel/entry/common.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/entry/common.c b/kernel/entry/common.c index 44fd089d59da..fdb0c543539d 100644 --- a/kernel/entry/common.c +++ b/kernel/entry/common.c @@ -6,6 +6,8 @@ #include #include +#include "common.h" + #define CREATE_TRACE_POINTS #include @@ -47,6 +49,12 @@ static inline long do_syscall_intercept(struct pt_regs *regs) int sysint_work = READ_ONCE(current->syscall_intercept); int ret; + if (sysint_work & SYSINT_USER_DISPATCH) { + ret = do_syscall_user_dispatch(regs); + if (ret == -1L) + return ret; + } + if (sysint_work & SYSINT_SECCOMP) { ret = __secure_computing(NULL); if (ret == -1L) -- 2.28.0