From owner-freebsd-arch@FreeBSD.ORG Sun Feb 19 10:49:06 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0957E106566C; Sun, 19 Feb 2012 10:49:06 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC2C8FC08; Sun, 19 Feb 2012 10:49:04 +0000 (UTC) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1J7hGUl022890; Sun, 19 Feb 2012 18:43:16 +1100 Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1J7hCpT011087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Feb 2012 18:43:13 +1100 Date: Sun, 19 Feb 2012 18:43:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Don Lewis In-Reply-To: <201202190101.q1J11cnJ017127@gw.catspoiler.org> Message-ID: <20120219170935.I873@besplex.bde.org> References: <201202190101.q1J11cnJ017127@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ae@FreeBSD.org, dougb@FreeBSD.org, arch@FreeBSD.org Subject: Re: [patch] allow crash dumps to Linux swap partitions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 10:49:06 -0000 On Sat, 18 Feb 2012, Don Lewis wrote: > On 18 Feb, Doug Barton wrote: >> On 02/18/2012 16:54, Don Lewis wrote: >>> On 18 Feb, Doug Barton wrote: >>>> On 02/18/2012 09:50, Andrey V. Elsukov wrote: >>>>> I think we can check bp->bio_from field, something like that (not tested): >>>> >>>> That made dumpon happy anyway, thanks! I'm a bit rusty on "how to cause >>>> a dump on purpose" nowadays .... I'm running 8-stable right now, if >>>> someone wants to give me a hint I'll test this. >>> >>> Break into DDB and type "call doadump". >> >> Yeah, that's what I used to do, but Ctrl-Alt-Esc didn't do anything for >> me. Do I have to compile in options BREAK_TO_DEBUGGER even on a desktop? > Looks like it. I've got that option in my custom kernel config files > that start with "include GENERIC". This is not needed, since there is a sysctl (debug.kdb_break_to_debugger) and a tunable for it. But everything for configuration of this is broken. I reported the following bugs in more detail to the breaker, but received no reply. 1. BREAK_TO_DEBUGGER means "enter the debugger on a serial line break", not "use a breakpoint trap to enter the debugger". That was just confusing, but now BREAK_TO_DEBUGGER is abused for the latter (only as the default for the static configuration, but that is bad enough). The sysctl and the tunable repeat the naming error in lower case. The function name kdb_break() adds to the confusion (this function does the breakpoint trap, using 2 layers of wrappers to add bugs). 2. Serial line breaks to enter the debugger are too painful to use in practice, since they occur when you unplug the cable, which you often do when you are not looking at the console so you don't notice that the system stopped in ddb. So someone implemented an alternative way to enter the debugger from serial consoles. This was and is misnamed ALT_BREAK_TO_DEBUGGER. This increases the confusion -- it gave an alternative way to a serial line break of entering the debugger (it wasn't an alternative to BREAK_TO_DEBUGGER, since both could be configured and they worked mostly independently). Now it is abused as (the default for control of) a general alternative way of entering the debugger. 3. Since BREAK_TO_DEBUGGER is too hard to use for its correct purpose if you _might_ have a serial console (which is in all configurations that have a serial driver that support consoles, since you can enable this support dynamically), you have to leave it unconfigured, at least statically. This breaks debugger entry on the syscons console. 4. Sysons has its own static and dynamic configuration corresponding to serial drivers' previously semi-private BREAK_TO_DEBUGGER: - SC_DISABLE_KDBKEY gives static configuration (default enabled) - the hw.syscons_kbd_debug sysctl (default enabled) gives dynamic configuration. There is no tunable for this, and though I hate tunables, it makes sense to have one for this -- it may need to be used before booting to close a security hole. It doesn't help that the sysctls and tunables are undocumented (?), and in different namespaces, yet kbd looks too much like kdb. 5. The BREAK_TO_DEBUGGER/debug.kdb_break_to_debugger controls are worse than the old sysctl controls, since they are too global. You can view them as global controls for extra security, with all subsystems that support consoles being required to have local controls, with the access control being the AND of all the enables, but this is too complicated and only supported accidentally by 1 set of local controls in 1 driver (syscons). 6. To work around some of the above bugs, I keep leaving BREAK_TO_DEBUGGER out of static configurations, and set debug.kdb_break_to_debugger in rc. The latter doesn't break serial consoles since I only do this on systems with no serial consoles. This works, except when the system crashes early (can't run sysctl) or when booting to the single user shell (have to do the sysctl manually). I always configure ALT_BREAK_TO_DEBUGGER, since it causes no problems for serial consoles, but it is harder to use. 7. Next, there are the configuration bugs and security holes from configuring ALT_BREAK_TO_DEBUGGER. It used to be just for serial consoles. Now it is for all consoles. If you turn it on so that it works for one console, then it works for all, since are no local controls for it. Syscons' old local controls corresponding to the serial line break controls are defeated in another way by this. It doesn't help security to disable debugger entries via the syscons hotkeys if the escape sequence can be used. For complicated configurations, with multiple serial consoles and only some trusted for input, there must be local controls on every device. Even per-driver is too coarse, and we only had per-subsystem-group (all tty drivers together, with syscons special). The global controls just let you quickly close any security holes in misconfigured consoles, at the cost of more confusion and complexity in both simple and complicated configurations. Bruce