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