On Fri, Sep 25, 2020 at 12:15:54PM -0400, Gabriel Krisman Bertazi wrote: > Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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
