Date: Sun, 19 Feb 2012 18:43:12 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Don Lewis <truckman@FreeBSD.org> Cc: ae@FreeBSD.org, dougb@FreeBSD.org, arch@FreeBSD.org Subject: Re: [patch] allow crash dumps to Linux swap partitions Message-ID: <20120219170935.I873@besplex.bde.org> In-Reply-To: <201202190101.q1J11cnJ017127@gw.catspoiler.org> References: <201202190101.q1J11cnJ017127@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120219170935.I873>