Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2687498imm; Mon, 16 Jul 2018 12:18:38 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdXQ/QsPcx8qiPorKHSwFq4ZDjLO4+vRPDbRYhqEE+HX/F1UTKtHTykn67WkYzPvDhAQKLP X-Received: by 2002:a62:42d7:: with SMTP id h84-v6mr19230010pfd.146.1531768718487; Mon, 16 Jul 2018 12:18:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531768718; cv=none; d=google.com; s=arc-20160816; b=WJyT5jfa2AEtCCMW6cSwc/+IZIENx2nv3ex0Lz/k7IIQdx90KL8nfY53/PPFUwLbvg DbOif5uKstdGEkxbDX2M4a4H3CjMKnw3a/gxv2JDx6C5I22H6FD6QioQu8ohc5lkLcnO zMww00BKP+e39ar0ogV0reBqGa7vVsKrs6iAdIVuK85NpnY/xkbpXARUA7ch0ifFxYyC GAp5d+ydeZKxlTfYbZ6jz7t9rRZDC6c/3rQYMogupHjJDogldUMi3AI+2nDHlnPNqYM0 MVBLJJeFWnk5KdXjQBjLYfKb27qRpyFBj9ne/RIiWVeyjlk3yEFLD8pKn4hQrbhppTTH y8Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from :arc-authentication-results; bh=GgPN8duI0+mbLaUuN2O9kmXtu06oP4bRmBqYEw+uc2M=; b=rIh6LWDqvFFsbBYolXiBA+iXEuwYFVfPQdB/gtDiHytq7vMwX0mDmNwsaQjnk2ziEp 0WiduF06drwwb2uNvpVfVHpBMoW39VtjR+8qQv76+InAUBDGNFQm5xT/g+JH45Hip7RQ yaX8+I9qFhsUfmseMjWwKnpgLJuxs7chBbb9BvCxxcWzYeDULksFZ8y8ULGlyYkDhFZm 22PyM3kBO3zvF1Uf+a1QQNtknlNaNjLaURCErn5qzV4sv1uJq8qpokLVivcKjmeNKU31 xGYlbIIZVgjBhSZiXHdLqKnadhzhDbzJI3rqZ6o3R7brvWW6LWqJXVoOpnUfjqVOzTmg MCNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y12-v6si13568472plr.55.2018.07.16.12.18.23; Mon, 16 Jul 2018 12:18:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728556AbeGPTqa (ORCPT + 99 others); Mon, 16 Jul 2018 15:46:30 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:45462 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727809AbeGPTqa (ORCPT ); Mon, 16 Jul 2018 15:46:30 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1ff907-000411-Gj; Mon, 16 Jul 2018 13:17:39 -0600 Received: from [97.119.167.31] (helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1ff906-00014o-NP; Mon, 16 Jul 2018 13:17:39 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Oleg Nesterov , Andrew Morton , Linux Kernel Mailing List , Wen Yang , majiang References: <877em2jxyr.fsf_-_@xmission.com> <20180711024459.10654-9-ebiederm@xmission.com> <20180716145540.GA20960@redhat.com> <87lgabrzfd.fsf@xmission.com> Date: Mon, 16 Jul 2018 14:17:33 -0500 In-Reply-To: (Linus Torvalds's message of "Mon, 16 Jul 2018 09:50:28 -0700") Message-ID: <87pnznkn1u.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1ff906-00014o-NP;;;mid=<87pnznkn1u.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.119.167.31;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+dIDm586apRjBh1y5xVeaE9bt8XQ1Excg= X-SA-Exim-Connect-IP: 97.119.167.31 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa08.xmission.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TR_Symld_Words,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01, XMGappySubj_01,XMNoVowels,XMSubLong autolearn=disabled version=3.4.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.5 XMGappySubj_01 Very gappy subject * 1.5 TR_Symld_Words too many words that have symbols inside * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa08 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa08 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 364 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.1 (0.9%), b_tie_ro: 2.2 (0.6%), parse: 0.81 (0.2%), extract_message_metadata: 12 (3.4%), get_uri_detail_list: 3.0 (0.8%), tests_pri_-1000: 6 (1.6%), tests_pri_-950: 1.12 (0.3%), tests_pri_-900: 0.96 (0.3%), tests_pri_-400: 35 (9.6%), check_bayes: 34 (9.3%), b_tokenize: 11 (3.0%), b_tok_get_all: 12 (3.3%), b_comp_prob: 3.1 (0.9%), b_tok_touch_all: 4.7 (1.3%), b_finish: 0.74 (0.2%), tests_pri_0: 297 (81.8%), check_dkim_signature: 0.52 (0.1%), check_dkim_adsp: 3.7 (1.0%), tests_pri_500: 4.7 (1.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC][PATCH 09/11] tty_io: Use do_send_sig_info in __do_SACK to forcibly kill tasks X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds writes: > On Mon, Jul 16, 2018 at 8:08 AM Eric W. Biederman wrote: >> >> The change for global init is it will now die if init is a member of the >> session or init is using this tty as it's controlling tty. >> >> Semantically killing init with SAK is completely appropriate. > > No. > > Semtnaitcally killing init is completely wrong. Because it will kill > the whole system. > > And I don't mean that in "now init won't spawn new things". I mean > that in "now we don't have a child reaper any more, and the system > will be dead because we'll panic on exit". > > So it's not about the controlling tty, it's about fundamental kernel > internal consistency guarantees. > > See > > write_unlock_irq(&tasklist_lock); > if (unlikely(pid_ns == &init_pid_ns)) { > panic("Attempted to kill init! exitcode=0x%08x\n", > father->signal->group_exit_code ?: father->exit_code); > } > > in kernel/exit.c. I should have said it doesn't matter because init does not open ttys and become a member of session groups. Or at least it never has in my experience. The only way I know to get that behavior is to boot with init=/bin/bash. With the force_sig already in do_SAK today my change is not a regression. As force_sig in a completely different way forces the signal to init. Looking deeper, all of the silliness with SEND_SIG_FORCED and force_sig_info is to guarantee delivery of synchronous exceptions even to init. So I think we want the patch below to clean that up. Then we don't have to worry about the wrong things sending signals to init by accident, and SEND_SIG_FORCED becomes just SEND_SIG_PRIV that skips the unnecesary allocation of a siginfo struct. Thoughts? Eric From: "Eric W. Biederman" Date: Mon, 16 Jul 2018 13:29:04 -0500 Subject: [PATCH] signal: Cleanup delivery of exceptions to init - Stop clearing SIGNAL_UNKILLABLE. It makes interaction by the process with other signals problematic, and exceptions are not necessarily fatal. - Don't allow SIGKILL and SIGSTOP to the global init. It never helps and it it can only make things worse. - Explicitly allow exceptions to any kind of init. They are exceptions and synchronous and need to be handled somehow. Init can setup a handler or deal with the default action. This is not a change it is just code movement from force_sig_info into send_signal and get_signal. - Treat all signals from the kernel as if they are from an ancestor pid namespace. - Take out the overrides of SIGNAL_UNKILLABLE from force_sig_info The changes to send_signal and get_signal make them unnecessary. - Take out the SEND_SIG_FORCED overrides from prepare_signal. The changes to send_signal makes it redundant. - Rename force back to from_ancestor_ns as that makes the logic with respect to namespaces clearer and logically if the kernel is sending you a signal it is from your ancestor namespace. Signed-off-by: "Eric W. Biederman" --- kernel/signal.c | 41 ++++++++++++++++------------------------- 1 file changed, 16 insertions(+), 25 deletions(-) diff --git a/kernel/signal.c b/kernel/signal.c index 94296afacf44..298f5c690681 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -72,20 +72,21 @@ static int sig_handler_ignored(void __user *handler, int sig) (handler == SIG_DFL && sig_kernel_ignore(sig)); } -static int sig_task_ignored(struct task_struct *t, int sig, bool force) +static int sig_task_ignored(struct task_struct *t, int sig, bool from_ancestor_ns) { void __user *handler; handler = sig_handler(t, sig); if (unlikely(t->signal->flags & SIGNAL_UNKILLABLE) && - handler == SIG_DFL && !(force && sig_kernel_only(sig))) + handler == SIG_DFL && + (is_global_init(t) || !(from_ancestor_ns && sig_kernel_only(sig)))) return 1; return sig_handler_ignored(handler, sig); } -static int sig_ignored(struct task_struct *t, int sig, bool force) +static int sig_ignored(struct task_struct *t, int sig, bool from_ancestor_ns) { /* * Blocked signals are never ignored, since the @@ -103,7 +104,7 @@ static int sig_ignored(struct task_struct *t, int sig, bool force) if (t->ptrace && sig != SIGKILL) return 0; - return sig_task_ignored(t, sig, force); + return sig_task_ignored(t, sig, from_ancestor_ns); } /* @@ -809,7 +810,7 @@ static void ptrace_trap_notify(struct task_struct *t) * Returns true if the signal should be actually delivered, otherwise * it should be dropped. */ -static bool prepare_signal(int sig, struct task_struct *p, bool force) +static bool prepare_signal(int sig, struct task_struct *p, bool from_ancestor_ns) { struct signal_struct *signal = p->signal; struct task_struct *t; @@ -871,7 +872,7 @@ static bool prepare_signal(int sig, struct task_struct *p, bool force) } } - return !sig_ignored(p, sig, force); + return !sig_ignored(p, sig, from_ancestor_ns); } /* @@ -1008,8 +1009,7 @@ static int __send_signal(int sig, struct kernel_siginfo *info, struct task_struc assert_spin_locked(&t->sighand->siglock); result = TRACE_SIGNAL_IGNORED; - if (!prepare_signal(sig, t, - from_ancestor_ns || (info == SEND_SIG_FORCED))) + if (!prepare_signal(sig, t, from_ancestor_ns)) goto ret; pending = (type != PIDTYPE_PID) ? &t->signal->shared_pending : &t->pending; @@ -1107,12 +1107,8 @@ static int __send_signal(int sig, struct kernel_siginfo *info, struct task_struc static int send_signal(int sig, struct kernel_siginfo *info, struct task_struct *t, enum pid_type type) { - int from_ancestor_ns = 0; - -#ifdef CONFIG_PID_NS - from_ancestor_ns = si_fromuser(info) && + int from_ancestor_ns = !si_fromuser(info) || !task_pid_nr_ns(current, task_active_pid_ns(t)); -#endif return __send_signal(sig, info, t, type, from_ancestor_ns); } @@ -1178,8 +1174,8 @@ int do_send_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *p * since we do not want to have a signal handler that was blocked * be invoked when user space had explicitly blocked it. * - * We don't want to have recursive SIGSEGV's etc, for example, - * that is why we also clear SIGNAL_UNKILLABLE. + * Exceptions are always delivered so we don't need to worry + * about init or other processes blocking exception signals. */ int force_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *t) @@ -1199,12 +1195,6 @@ force_sig_info(int sig, struct kernel_siginfo *info, struct task_struct *t) recalc_sigpending_and_wake(t); } } - /* - * Don't clear SIGNAL_UNKILLABLE for traced tasks, users won't expect - * debugging to leave init killable. - */ - if (action->sa.sa_handler == SIG_DFL && !t->ptrace) - t->signal->flags &= ~SIGNAL_UNKILLABLE; ret = send_signal(sig, info, t, PIDTYPE_PID); spin_unlock_irqrestore(&t->sighand->siglock, flags); @@ -2536,9 +2526,10 @@ int get_signal(struct ksignal *ksig) continue; /* - * Global init gets no signals it doesn't want. - * Container-init gets no signals it doesn't want from same - * container. + * Except for synchronous exceptions (!SI_FROMUSER) + * global init gets no signals it doesn't want, and + * container-init gets no signals it doesn't want from + * same container. * * Note that if global/container-init sees a sig_kernel_only() * signal here, the signal must have been generated internally @@ -2546,7 +2537,7 @@ int get_signal(struct ksignal *ksig) * case, the signal cannot be dropped. */ if (unlikely(signal->flags & SIGNAL_UNKILLABLE) && - !sig_kernel_only(signr)) + !sig_kernel_only(signr) && SI_FROMUSER(&ksig->info)) continue; if (sig_kernel_stop(signr)) { -- 2.17.1