From owner-svn-src-all@freebsd.org Thu Mar 22 06:03:36 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4343F6CFB1; Thu, 22 Mar 2018 06:03:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 34CAC81CC7; Thu, 22 Mar 2018 06:03:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id EDC0ED48D99; Thu, 22 Mar 2018 17:03:25 +1100 (AEDT) Date: Thu, 22 Mar 2018 17:03:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Warner Losh , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r331298 - head/sys/dev/syscons In-Reply-To: <20180321202752.GO76926@kib.kiev.ua> Message-ID: <20180322155152.O1053@besplex.bde.org> References: <201803211447.w2LElDcK091988@repo.freebsd.org> <20180322024846.S4293@besplex.bde.org> <20180321202752.GO76926@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=SHKZrRbqEoQg_kA9z3AA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 06:03:36 -0000 On Wed, 21 Mar 2018, Konstantin Belousov wrote: > On Thu, Mar 22, 2018 at 04:53:22AM +1100, Bruce Evans wrote: >> Serial console drivers with fast interrupt handlers have much more >> broken locking for ddb special keys. It is invalid to either drop locks >> or call the "any" function from a fast interrupt handler, but buggy >> serial console drivers calls kbd_alt_break(), and that now calls >> shutdown_nice() and other functions that cannot be called from a fast >> interrupt handler. ddb keys supply most of the shutdown_nice() >> functionality for serial consoles, and there are no escape sequence to >> get this without ddb or maybe another debugger, so these bugs don't >> affect most users. >> >> Handling this correctly requires much the same fix as an unsafe signal >> handler, and fixes have much the same problems -- not much more than >> setting a flag is safe, and the flag might never be looked at if the >> system is in a bad state. However, if a nice shutdown is possible then >> the sytem must be in a good enough state to poll for flags. > > Are you saying that fast interrupt handlers call shutdown_nice() ? This > is the quite serious bug on its own. To fix it, shutdown_nice() should > use a fast taskqueue to schedule the task which would lock the process > and send the signal. Yes. See kdb_reboot(). This is called for an escape sequence from kdb_alt_break_internal(). The other calls in kdb_alt_break_internal() don't wander into a function that calls shutdown_nice() and are relatively safe. They have to be not completely safe to work in "any" context. kdb_reboot() is the opposite -- we want it to fail if the context is not nice enough to reboot nicely. BTW, I've often wanted to be able to send more general signals to init using keystrokes, independent of being logged in. Mainly SIGHUP to shut down to single user mode. This has some security problems, especially for the "any" signal to the "any" process. At least syscons defaults to allowing Ctrl-Alt-Del to reboot. I like that and miss it on serial consoles and on some non-FreeBSD OS's (the alt-break sequence to reach kdb_reboot() is not equivalent, since it is only available if much more insecure sequences are also allowed). Shutdown isn't as fundamentally insecure as sending arbitrary signals and most systems allow it without much more than a password for users that have physical access to the system. OTOH, I don't like the syscons key that suspends. This is also allowed by default. I sometimes press it by mistake on a system that can suspend but not resume. Unlike the reboot key, there are no knobs for controlling it. There are 3 static configuration knobs, 2 sysctls and the keymap which must be understood for securing the main reboot key in syscons, and a slightly different set of controls in vt :-(. For suspend, there is only the keymap. Syscons also has a standby key and more shutdown keys, but these are in more obscure parts of keymaps and I've never noticed typing them by mistake. Bruce