Re: [PATCH v6 4/6] task_isolation: provide strict mode configurable signal

Andy Lutomirski
2015-08-28T19:23:03Z

On Tue, Aug 25, 2015 at 12:55 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> Allow userspace to override the default SIGKILL delivered
> when a task_isolation process in STRICT mode does a syscall
> or otherwise synchronously enters the kernel.
>
> In addition to being able to set the signal, we now also
> pass whether or not the interruption was from a syscall in
> the si_code field of the siginfo.
>
> Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
> ---
> include/uapi/linux/prctl.h | 2 ++
> kernel/isolation.c | 17 +++++++++++++----
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
> index e16e13911e8a..2a4ddc890e22 100644
> --- a/include/uapi/linux/prctl.h
> +++ b/include/uapi/linux/prctl.h
> @@ -195,5 +195,7 @@ struct prctl_mm_map {
> #define PR_GET_TASK_ISOLATION 48
> # define PR_TASK_ISOLATION_ENABLE (1 << 0)
> # define PR_TASK_ISOLATION_STRICT (1 << 1)
> +# define PR_TASK_ISOLATION_SET_SIG(sig) (((sig) & 0x7f) << 8)
> +# define PR_TASK_ISOLATION_GET_SIG(bits) (((bits) >> 8) & 0x7f)
>
> #endif /* _LINUX_PRCTL_H */
> diff --git a/kernel/isolation.c b/kernel/isolation.c
> index a89a6e9adfb4..b776aa632c8f 100644
> --- a/kernel/isolation.c
> +++ b/kernel/isolation.c
> @@ -75,11 +75,20 @@ void task_isolation_enter(void)
> }
> }
>
> -static void kill_task_isolation_strict_task(void)
> +static void kill_task_isolation_strict_task(int is_syscall)
> {
> + siginfo_t info = {};
> + int sig;
> +
> dump_stack();
> current->task_isolation_flags &= ~PR_TASK_ISOLATION_ENABLE;
> - send_sig(SIGKILL, current, 1);
> +
> + sig = PR_TASK_ISOLATION_GET_SIG(current->task_isolation_flags);
> + if (sig == 0)
> + sig = SIGKILL;
> + info.si_signo = sig;
> + info.si_code = is_syscall;
> + send_sig_info(sig, &info, current);

The stuff you're doing here is sufficiently nasty that I think you
should add something like:

rcu_lockdep_assert(rcu_is_watching(), "some message here");

Because as it stands this is just asking for trouble.

For the record, I am *extremely* unhappy with the state of the context
tracking hooks.

--Andy