From: Kees Cook <keescook@chromium.org>
To: Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
luto@kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, willy@infradead.org,
linux-kselftest@vger.kernel.org, shuah@kernel.org,
kernel@collabora.com
Subject: Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag
Date: Fri, 25 Sep 2020 13:30:57 -0700 [thread overview]
Message-ID: <202009251327.587D111@keescook> (raw)
In-Reply-To: <87k0whsuh1.fsf@collabora.com>
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
next prev parent reply other threads:[~2020-09-25 20:38 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 20:31 [PATCH v6 0/9] Syscall User Dispatch Gabriel Krisman Bertazi
2020-09-04 20:31 ` [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag Gabriel Krisman Bertazi
2020-09-07 10:16 ` Christian Brauner
2020-09-08 4:59 ` Gabriel Krisman Bertazi
2020-09-22 19:42 ` Kees Cook
2020-09-23 20:28 ` Gabriel Krisman Bertazi
2020-09-11 9:32 ` peterz
2020-09-11 20:08 ` Gabriel Krisman Bertazi
2020-09-24 11:24 ` Peter Zijlstra
2020-09-22 19:44 ` Kees Cook
2020-09-23 20:18 ` Gabriel Krisman Bertazi
2020-09-23 20:49 ` Kees Cook
2020-09-25 8:00 ` Thomas Gleixner
2020-09-25 16:15 ` Gabriel Krisman Bertazi
2020-09-25 20:30 ` Kees Cook [this message]
2020-09-04 20:31 ` [PATCH v6 2/9] kernel: entry: Support TIF_SYSCAL_INTERCEPT on common entry code Gabriel Krisman Bertazi
2020-09-07 10:16 ` Christian Brauner
2020-09-11 9:35 ` peterz
2020-09-11 20:11 ` Gabriel Krisman Bertazi
2020-09-04 20:31 ` [PATCH v6 3/9] x86: vdso: Expose sigreturn address on vdso to the kernel Gabriel Krisman Bertazi
2020-09-22 19:40 ` Kees Cook
2020-09-04 20:31 ` [PATCH v6 4/9] signal: Expose SYS_USER_DISPATCH si_code type Gabriel Krisman Bertazi
2020-09-07 10:15 ` Christian Brauner
2020-09-22 19:39 ` Kees Cook
2020-09-04 20:31 ` [PATCH v6 5/9] kernel: Implement selective syscall userspace redirection Gabriel Krisman Bertazi
2020-09-05 11:24 ` Matthew Wilcox
2020-09-11 9:44 ` peterz
2020-09-04 20:31 ` [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry Gabriel Krisman Bertazi
2020-09-07 10:15 ` Christian Brauner
2020-09-07 14:15 ` Andy Lutomirski
2020-09-07 14:25 ` Christian Brauner
2020-09-07 20:20 ` Andy Lutomirski
2020-09-11 9:46 ` peterz
2020-09-04 20:31 ` [PATCH v6 7/9] x86: Enable Syscall User Dispatch Gabriel Krisman Bertazi
2020-09-22 19:37 ` Kees Cook
2020-09-23 20:23 ` Gabriel Krisman Bertazi
2020-09-04 20:31 ` [PATCH v6 8/9] selftests: Add kselftest for syscall user dispatch Gabriel Krisman Bertazi
2020-09-22 19:35 ` Kees Cook
2020-09-04 20:31 ` [PATCH v6 9/9] doc: Document Syscall User Dispatch Gabriel Krisman Bertazi
2020-09-22 19:35 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202009251327.587D111@keescook \
--to=keescook@chromium.org \
--cc=kernel@collabora.com \
--cc=krisman@collabora.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.