From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: [PATCH 2/2] seccomp.2: document userspace notification Date: Fri, 1 Mar 2019 16:13:46 +0100 Message-ID: <7a101bfc-b045-35f8-aa3f-a18ecc896fc8@gmail.com> References: <20181213001106.15268-1-tycho@tycho.ws> <20181213001106.15268-3-tycho@tycho.ws> <2cea5fec-e73e-5749-18af-15c35a4bd23c@gmail.com> <20190301145341.GD7413@cisco> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190301145341.GD7413@cisco> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Tycho Andersen Cc: mtk.manpages@gmail.com, "Serge E. Hallyn" , linux-man@vger.kernel.org, Kees Cook , Linux API , lkml , Andy Lutomirski , Jann Horn , Oleg Nesterov , Christian Brauner , "Eric W. Biederman" , Containers , Aleksa Sarai , Tyler Hicks , Akihiro Suda List-Id: linux-man@vger.kernel.org On 3/1/19 3:53 PM, Tycho Andersen wrote: > On Thu, Feb 28, 2019 at 02:25:55PM +0100, Michael Kerrisk (man-pages) wrote: >>> 7. The monitoring process can use the information in the >>> 'struct seccomp_notif' to make a determination about the >>> system call being made by the target process. This >>> structure includes a 'data' field that is the same >>> 'struct seccomp_data' that is passed to a BPF filter. >>> >>> In addition, the monitoring process may make use of other >>> information that is available from user space. For example, >>> it may inspect the memory of the target process (whose PID >>> is provided in the 'struct seccomp_notif') using >>> /proc/PID/mem, which includes inspecting the values >>> pointed to by system call arguments (whose location is >>> available 'seccomp_notif.data.args). However, when using >>> the target process PID in this way, one must guard against >>> PID re-use race conditions using the seccomp() >>> SECCOMP_IOCTL_NOTIF_ID_VALID operation. >>> >>> 8. Having arrived at a decision about the target process's >>> system call, the monitoring process can inform the kernel >>> of its decision using the operation >>> >>> ioctl(listenfd, SECCOMP_IOCTL_NOTIF_SEND, respptr) >>> >>> where the third argument is a pointer to a >>> 'struct seccomp_notif_resp'. [Some more details >>> needed here, but I still don't yet understand fully >>> the semantics of the 'error' and 'val' fields.] >> >> So clearly, I misunderstood these last two steps. >> >> (7) is something like: discover information in userspace >> as required; perform userspace actions if appropriate >> (perhaps doing the system call operation "on behalf of" the >> target process). >> >> >> (8) is something like: >> set 'error' and 'val' to return info to the target process: >> * error != 0 ==> make it look like the syscall failed, >> with 'errno' set to that value That piece should be amended: error < 0 ==> make it look like syscall failed. error > 0 ==> make it look like the syscall succeeded and returned 'error' Is that really supposed to happen? >> * error == 0 ==> make it look like the syscall succeeded >> and returned 'val' Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/