linux-kernel - Re: [PATCH 3/4] seccomp: Support atomic "addfd + send reply"

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 May 2021 15:50:10 -0600
From:   Tycho Andersen <tycho@...ho.pizza>
To:     Sargun Dhillon <sargun@...gun.me>
Cc:     Kees Cook <keescook@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Containers <containers@...ts.linux.dev>,
        Andy Lutomirski <luto@...nel.org>,
        Rodrigo Campos <rodrigo@...volk.io>,
        Mauricio Vásquez Bernal 
        <mauricio@...volk.io>, Giuseppe Scrivano <gscrivan@...hat.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH 3/4] seccomp: Support atomic "addfd + send reply"

Hi,

On Sat, May 01, 2021 at 05:18:50PM -0700, Sargun Dhillon wrote:

[snip]

> Other patches in this series add a way to block signals when a syscall
> is put to wait by seccomp.

I guess we can drop this bit from the message if the series is split.

> The struct seccomp_notif_resp, used when doing SECCOMP_IOCTL_NOTIF_SEND
> ioctl() to send a response to the target, has three more fields that we
> don't allow to set when doing the addfd ioctl() to also return. The
> reasons to disallow each field are:
>  * val: This will be set to the new allocated fd. No point taking it
>    from userspace in this case.
>  * error: If this is non-zero, the value is ignored. Therefore,
>    it is pointless in this case as we want to return the value.
>  * flags: The only flag is to let userspace continue to execute the
>    syscall. This seems pointless, as we want the syscall to return the
>    allocated fd.
> 
> This is why those fields are not possible to set when using this new
> flag.

I don't quite understand this; you don't need a NOTIF_SEND at all
with the way this currently works, right?

> @@ -1113,7 +1136,7 @@ static int seccomp_do_user_notification(int this_syscall,
>  						 struct seccomp_kaddfd, list);
>  		/* Check if we were woken up by a addfd message */
>  		if (addfd)
> -			seccomp_handle_addfd(addfd);
> +			seccomp_handle_addfd(addfd, &n);
>  
>  	}  while (n.state != SECCOMP_NOTIFY_REPLIED);
>  

This while() bit is introduced in the previous patch, can we fold this
deletion into that somehow?

Thanks,

Tycho