Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxx]
> Sent: 06 November 2018 10:28
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>; Ian Jackson
> <Ian.Jackson@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to
> chroot
> 
> On 11/06/2018 09:14 AM, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On
> Behalf
> >> Of George Dunlap
> >> Sent: 05 November 2018 18:07
> >> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>; Ian Jackson
> >> <Ian.Jackson@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; George Dunlap
> >> <George.Dunlap@xxxxxxxxxx>
> >> Subject: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to
> chroot
> >>
> >> When dm_restrict is enabled, ask QEMU to chroot into an empty
> directory.
> >>
> >> * Create /var/run/qemu/root-domid (deleting the old one if it's there)
> >
> > This does not appear to match the code: the path should be
> /var/run/qemu-root-<domid> AFAICT
> 
> Indeed, I forgot to update this.  I can fix this up on check-in.
> 
> >> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> >> index 26eb16af34..ad3efcc783 100644
> >> --- a/tools/libxl/libxl_dm.c
> >> +++ b/tools/libxl/libxl_dm.c
> >> @@ -1410,9 +1410,48 @@ static int
> >> libxl__build_device_model_args_new(libxl__gc *gc,
> >>          }
> >>      }
> >>
> >> -    if (libxl_defbool_val(b_info->dm_restrict))
> >> +    if (libxl_defbool_val(b_info->dm_restrict)) {
> >> +        char *chroot_dir = GCSPRINTF("%s/qemu-root-%d",
> >> +                                      libxl__run_dir_path(),
> >> guest_domid);
> >> +        int r;
> >> +
> >>          flexarray_append(dm_args, "-xen-domid-restrict");
> >>
> >> +        /*
> >> +         * Run QEMU in a chroot at XEN_RUN_DIR/qemu-root-%d
> >
> > Maybe '<domid>' in the comment rather than '%d'?
> 
> Maybe. :-)
> 
> >> +         *
> >> +         * There is no library function to do the equivalent of `rm
> >> +         * -rf`.  However deprivileged QEMU in theory shouldn't be
> >> +         * able to write any files, as the chroot would be owned by
> >> +         * root, but it would be running as an unprivileged process.
> >> +         * So in theory, old chroots should always be empty.
> >
> > How does logging work if QEMU can't write to the chroot? I assume we are
> relying on stderr? Does using syslog still work?
> 
> Everything QEMU needs access to (including vnc sockets, qmp sockets, &c)
> must either be opened before the chroot happens, or passed to QEMU as an
> fd via qmp.  In the case of logging, this happens through stderr; but if
> you search for 'chroot' in the design document you'll get a couple of
> examples of different issues that need to be addressed (including
> inserting a cd-rom and dealing with migration).

Ok. The trace backend is set at build time in tools/Makefile:

        if $$source/scripts/tracetool.py --check-backend --backend log ; then \
                enable_trace_backend='--enable-trace-backend=log'; 
        elif $$source/scripts/tracetool.py --check-backend --backend stderr ; 
then \
                enable_trace_backend='--enable-trace-backend=stderr'; \
        else \
                enable_trace_backend='' ; \
        fi ; \

and log appears to favoured. Is this still going to work with the chroot? We 
rely on the tracing in xen_platform to get log messages out of PV drivers.

  Paul

> 
>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel