diff mbox series

tools/libs/light: don't allow to stop Xenstore stubdom

Message ID 20240206124345.19433-1-jgross@suse.com (mailing list archive)
State New, archived
Headers show
Series tools/libs/light: don't allow to stop Xenstore stubdom | expand

Commit Message

Jürgen Groß Feb. 6, 2024, 12:43 p.m. UTC
A Xenstore stubdom should never be stoppable.

Reject attempts to do so.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/libs/light/libxl_domain.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comments

Andrew Cooper Feb. 6, 2024, 1:08 p.m. UTC | #1
On 06/02/2024 12:43 pm, Juergen Gross wrote:
> A Xenstore stubdom should never be stoppable.
>
> Reject attempts to do so.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

I don't think this is a clever idea.  `xl destroy` is also the "please
clean up my system when it's in a very dead state" command, and that
also includes a dead xenstored stubdom.

If you're looking for some protection, then maybe a `--force` flag to
override, but there must be some way of getting this to run.

~Andrew
Jürgen Groß Feb. 6, 2024, 1:43 p.m. UTC | #2
On 06.02.24 14:08, Andrew Cooper wrote:
> On 06/02/2024 12:43 pm, Juergen Gross wrote:
>> A Xenstore stubdom should never be stoppable.
>>
>> Reject attempts to do so.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> I don't think this is a clever idea.  `xl destroy` is also the "please
> clean up my system when it's in a very dead state" command, and that
> also includes a dead xenstored stubdom.

I don't think xl destroy for a dead Xenstore stubdom will ever work.
xl destroy tries to read (and delete) Xenstore entries, after all.

I think you'd need a program using libxenctrl without all the xl/libxl
actions for achieving this goal. And this would work with my current
patch, too.

> If you're looking for some protection, then maybe a `--force` flag to
> override, but there must be some way of getting this to run.

A system without Xenstore is probably quite useless anyway. At least today
there is no way a new Xenstore would be able to connect to existing domains.

OTOH I'm inclined to add more hooks, e.g. for "xl pause" and "xl migrate".

And I do think that libxl is the right level for that, as I don't want users
to be able to kill/pause/migrate Xenstore stubdom via libvirt either.


Juergen
diff mbox series

Patch

diff --git a/tools/libs/light/libxl_domain.c b/tools/libs/light/libxl_domain.c
index 5ee1544d9c..21d1b0babf 100644
--- a/tools/libs/light/libxl_domain.c
+++ b/tools/libs/light/libxl_domain.c
@@ -1167,13 +1167,19 @@  void libxl__destroy_domid(libxl__egc *egc, libxl__destroy_domid_state *dis)
 {
     STATE_AO_GC(dis->ao);
     uint32_t domid = dis->domid;
+    libxl_dominfo info;
     int rc;
 
     libxl__ev_child_init(&dis->destroyer);
 
-    rc = libxl_domain_info(CTX, NULL, domid);
+    rc = libxl_domain_info(CTX, &info, domid);
     switch(rc) {
     case 0:
+        if (info.never_stop) {
+            LOGD(ERROR, domid, "Non-stoppable domain");
+            rc = ERROR_INVAL;
+            goto out;
+        }
         break;
     case ERROR_DOMAIN_NOTFOUND:
         LOGD(ERROR, domid, "Non-existant domain");