On Fri, Jan 03, 2020 at 09:17:58PM +0100, Mark Kettenis wrote:
> The command isn't actually as dangerous as you think. You can
> continue from the ddb prompt just fine...
That assumes one has access to the console. I hope everyone running
such setups has, but needing to resort to OOB access for serial when I
screw up over SSH and panic the primary is not convenient.
> A valid question is whether our kernel running in a domain should
> respond to this command. Maybe it should respect ddb.console?
Good question.
I'd argue `ldomctl panic' is in line with the means by wich ddb may be
entered:
DBCTL_CONSOLE (ddb.console)
When this variable is set, an architecture dependent magic key
sequence on the console or a debugger button will permit entry
into the kernel debugger. When running with a securelevel(7)
greater than 0, this variable may not be raised.
Or: Why should ddb.console prevent "magic key", "debugger button" and
`sysctl ddb.panic' but allow `ldomctl console'?
Perhaps this level of overwrite is desired so that admins can always
panic guests regardless of the sysctl? Afterall guests have no influence
on the primary and its controlling actions, so why should this differ?
Writing this down, I tend to leave it as is; ldomctl *is* a control
command and honering guest parameters violates this principle.
