Messages in this thread | | | Date | Wed, 23 Sep 2020 13:49:54 -0700 | From | Kees Cook <> | Subject | Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag |
| |
On Wed, Sep 23, 2020 at 04:18:26PM -0400, Gabriel Krisman Bertazi wrote: > Kees Cook <keescook@chromium.org> writes: > > > On Fri, Sep 04, 2020 at 04:31:39PM -0400, Gabriel Krisman Bertazi wrote: > >> Convert TIF_SECCOMP into a generic TI flag for any syscall interception > >> work being done by the kernel. The actual type of work is exposed by a > >> new flag field outside of thread_info. This ensures that the > >> syscall_intercept field is only accessed if struct seccomp has to be > >> accessed already, such that it doesn't incur in a much higher cost to > >> the seccomp path. > >> > >> In order to avoid modifying every architecture at once, this patch has a > >> transition mechanism, such that architectures that define TIF_SECCOMP > >> continue to work by ignoring the syscall_intercept flag, as long as they > >> don't support other syscall interception mechanisms like the future > >> syscall user dispatch. When migrating TIF_SECCOMP to > >> TIF_SYSCALL_INTERCEPT, they should adopt the semantics of checking the > >> syscall_intercept flag, like it is done in the common entry syscall > >> code, or even better, migrate to the common syscall entry code. > > > > Can we "eat" all the other flags like ptrace, audit, etc, too? Doing > > this only for seccomp seems strange. > > Hi Kees, Thanks again for the review. > > Yes, we can, and I'm happy to follow up with that as part of my TIF > clean up work, but can we not block the current patchset to be merged > waiting for that, as this already grew a lot from the original feature > submission?
In that case, I'd say just add the new TIF flag. The consolidation can come later.
-- Kees Cook
| |