Messages in this thread | | | Date | Mon, 2 Jun 2014 13:06:51 -0700 | Subject | Re: [PATCH v5 0/6] seccomp: add PR_SECCOMP_EXT and SECCOMP_EXT_ACT_TSYNC | From | Kees Cook <> |
| |
On Mon, Jun 2, 2014 at 12:59 PM, Andy Lutomirski <luto@amacapital.net> wrote: > On Mon, Jun 2, 2014 at 12:47 PM, Kees Cook <keescook@chromium.org> wrote: >> Hi Andrew, >> >> Would you be willing to carry this series? Andy Lutomirski appears >> happy with it now. (Thanks again for all the feedback Andy!) If so, it >> has a relatively small merge conflict with the bpf changes living in >> net-next. Would you prefer I rebase against net-next, let sfr handle >> it, get carried in net-next, or some other option? > > Well, I'm still not entirely convinced that we want to have this much > multiplexing in a prctl, and I'm still a bit unconvinced that the code
I don't want to get caught without interface argument flexibility again, so that's why the prctl interface is being set up that way.
> wouldn't be better off it it were completely atomic in the sense that > it would either work or fail without doing anything.
Getting perfect atomic operation looks extremely hard given task locking. If this could get fixed in the future, it would have no impact on the interface. At present, the corner case of the racing thread is small enough that just catching the race failure is sufficient. If task locking is improved in the future, it could just simply never lose a race. Userspace still needs to handle errors no matter what is the non-race failure condition (mode 1 or forked filter) still exists.
-Kees
-- Kees Cook Chrome OS Security
| |