Re: ldomctl: Do not start/stop/panic primary domain
> Date: Mon, 30 Dec 2019 22:14:20 +0100 > From: Klemens Nanni > > `ldomctl start|stop primary" silently exits zero not doing anything, > `ldomctl panic primary" makes primary panic (and pulls guests down with > it). > > The manual explicitly documents those commands for "guest" domains, > code comments say so as well, so lets behave accordingly and prevent > stupid admins like me from testing `ldomctl panic primary' on their > machine before looking at the code. > > Feedback on better error message wording? > OK? Please no. Stupid sysadmins should stay away from that command ;). > Index: ldomctl.c > === > RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.c,v > retrieving revision 1.31 > diff -u -p -r1.31 ldomctl.c > --- ldomctl.c 28 Dec 2019 18:36:02 - 1.31 > +++ ldomctl.c 30 Dec 2019 21:10:39 - > @@ -426,6 +426,9 @@ guest_start(int argc, char **argv) > if (argc != 2) > usage(); > > + if (strcmp(argv[1], "primary") == 0) > + errx(1, "cannot start primary domain"); > + > /* >* Start guest domain. >*/ > @@ -452,6 +455,9 @@ guest_stop(int argc, char **argv) > if (argc != 2) > usage(); > > + if (strcmp(argv[1], "primary") == 0) > + errx(1, "cannot stop primary domain"); > + > /* >* Stop guest domain. >*/ > @@ -477,6 +483,9 @@ guest_panic(int argc, char **argv) > > if (argc != 2) > usage(); > + > + if (strcmp(argv[1], "primary") == 0) > + errx(1, "cannot panic primary domain"); > > /* >* Stop guest domain. > >
Re: ldomctl: Do not start/stop/panic primary domain
On Fri, Jan 03, 2020 at 08:28:54PM +0100, Mark Kettenis wrote: > Please no. Stupid sysadmins should stay away from that command ;). Do you want to scare them away? Fine with me, your call.
Re: ldomctl: Do not start/stop/panic primary domain
As a "Stupid Sysadmin", I want all the help I can get! :-) On Fri, 3 Jan 2020 at 19:56, Klemens Nanni wrote: > On Fri, Jan 03, 2020 at 08:28:54PM +0100, Mark Kettenis wrote: > > Please no. Stupid sysadmins should stay away from that command ;). > Do you want to scare them away? > > Fine with me, your call. > >
Re: ldomctl: Do not start/stop/panic primary domain
> Date: Fri, 3 Jan 2020 20:42:11 +0100 > From: Klemens Nanni > > On Fri, Jan 03, 2020 at 08:28:54PM +0100, Mark Kettenis wrote: > > Please no. Stupid sysadmins should stay away from that command ;). > Do you want to scare them away? > > Fine with me, your call. The command isn't actually as dangerous as you think. You can continue from the ddb prompt just fine... A valid question is whether our kernel running in a domain should respond to this command. Maybe it should respect ddb.console?
Re: ldomctl: Do not start/stop/panic primary domain
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.
