Messages in this thread |  | | Date | Fri, 25 Sep 2020 13:30:57 -0700 | From | Kees Cook <> | Subject | Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag |
| |
On Fri, Sep 25, 2020 at 12:15:54PM -0400, Gabriel Krisman Bertazi wrote: > Thomas Gleixner <tglx@linutronix.de> writes: > > > On Wed, Sep 23 2020 at 13:49, Kees Cook wrote: > >> On Wed, Sep 23, 2020 at 04:18:26PM -0400, Gabriel Krisman Bertazi wrote: > >>> Kees Cook <keescook@chromium.org> writes: > >>> 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. > > > > No. This is exactly the wrong order. Cleanup and consolidation have > > precedence over features. I'm tired of 'we'll do that later' songs, > > simply because in the very end I'm going to be the idiot who mops up the > > resulting mess. > > > > No problem. I will follow up with a patchset consolidating those flags > into this syscall_intercept interface I proposed. I assume there is no > immediate concerns with the consolidation approach itself.
I think the only issue is just finding a clean way to set/unset the flags safely/quickly (a lock seems too heavy to me).
Should thread_info hold an entire u32 for all intercept flags (then the TIF_WORK tests is just a zero-test of the intercept u32 word)? Or should there be a TIF_INTERCEPT and a totally separate u32 (e.g. in task_struct) indicating which intercepts? (And if they're separate, how do we atomically set/unset)
i.e.:
atomic_start toggle a per-intercept bit set TIF_INTERCEPT = !!(intercept word) atomic_end
-- Kees Cook
|  |