> -----Original Message-----
> From: George Dunlap [mailto:[email protected]]
> Sent: 06 November 2018 10:28
> To: Paul Durrant <[email protected]>; [email protected]
> Cc: Anthony Perard <[email protected]>; Ian Jackson
> <[email protected]>; Wei Liu <[email protected]>
> 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:[email protected]] On
> Behalf
> >> Of George Dunlap
> >> Sent: 05 November 2018 18:07
> >> To: [email protected]
> >> Cc: Anthony Perard <[email protected]>; Ian Jackson
> >> <[email protected]>; Wei Liu <[email protected]>; George Dunlap
> >> <[email protected]>
> >> 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
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
