| Message ID | 20240205105001.24171-1-jgross@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tools: enable xenstore-stubdom to use 9pfs | expand |
Hi Juergen, On 05/02/2024 10:49, Juergen Gross wrote: > This series is adding 9pfs support to Xenstore-stubdom, enabling it > to do logging to a dom0 directory. > > This is a prerequisite for the final goal to add live update support > to Xenstore-stubdom, as it enables the stubdom to store its state in > a dom0 file. > > The 9pfs backend is a new daemon written from scratch. Using a > dedicated 9pfs daemon has several advantages: > > - it is using much less resources than a full blown qemu process > - it can serve multiple guests (the idea is to use it for other > infrastructure domains, like qemu-stubdom or driver domains, too) > - it is designed to support several security enhancements, like > limiting the number of files for a guest, or limiting the allocated > file system space > - it doesn't support file links (neither hard nor soft links) or > referencing parent directories via "..", minimizing the risk that > a guest can "escape" from its home directory > > Note that for now the daemon only contains the minimal needed > functionality to do logging from Xenstore-stubdom. I didn't want to > add all the 9pfs commands and security add-ons in the beginning, in > order to avoid needless efforts in case the idea of the daemon is > being rejected. > > Changes in V4: > - patch 2 of V3 was applied > - added support of reading directories > - addressed review comments > > Changes in V3: > - new patches 1, 23-25 > - addressed review comments > > Changes in V2: > - support of multiple rings per device > - xenlogd->xen-9pfsd rename > - addressed review comments > - fixed some bugs > > Juergen Gross (32): > tools: add access macros for unaligned data > tools: add a new xen logging daemon > tools/xen-9pfsd: connect to frontend > tools/xen-9pfsd: add transport layer > tools/xen-9pfsd: add 9pfs response generation support > tools/xen-9pfsd: add 9pfs version request support > tools/xen-9pfsd: add 9pfs attach request support > tools/xen-9pfsd: add 9pfs walk request support > tools/xen-9pfsd: add 9pfs open request support > tools/xen-9pfsd: add 9pfs clunk request support > tools/xen-9pfsd: add 9pfs create request support > tools/xen-9pfsd: add 9pfs stat request support > tools/xen-9pfsd: add 9pfs write request support > tools/xen-9pfsd: add 9pfs read request support > tools/libs/light: add backend type for 9pfs PV devices > tools/xl: support new 9pfs backend xen_9pfsd > tools/helpers: allocate xenstore event channel for xenstore stubdom > tools/xenstored: rename xenbus_evtchn() > stubdom: extend xenstore stubdom configs > tools: add 9pfs device to xenstore-stubdom > tools/xenstored: add early_init() function > tools/xenstored: move systemd handling to posix.c > tools/xenstored: move all log-pipe handling into posix.c > tools/xenstored: move all socket handling into posix.c > tools/xenstored: get own domid in stubdom case > tools/xenstored: rework ring page (un)map functions > tools/xenstored: split domain_init() > tools/xenstored: map stubdom interface > tools/xenstored: mount 9pfs device in stubdom > tools/xenstored: add helpers for filename handling > tools/xenstored: support complete log capabilities in stubdom > tools/xenstored: have a single do_control_memreport() I haven't checked what's the state of the 9PFS patches. Can part of the xenstored changes be committed without the 9PFS changes? Cheers,
On 05.02.24 11:55, Julien Grall wrote: > Hi Juergen, > > On 05/02/2024 10:49, Juergen Gross wrote: >> This series is adding 9pfs support to Xenstore-stubdom, enabling it >> to do logging to a dom0 directory. >> >> This is a prerequisite for the final goal to add live update support >> to Xenstore-stubdom, as it enables the stubdom to store its state in >> a dom0 file. >> >> The 9pfs backend is a new daemon written from scratch. Using a >> dedicated 9pfs daemon has several advantages: >> >> - it is using much less resources than a full blown qemu process >> - it can serve multiple guests (the idea is to use it for other >> infrastructure domains, like qemu-stubdom or driver domains, too) >> - it is designed to support several security enhancements, like >> limiting the number of files for a guest, or limiting the allocated >> file system space >> - it doesn't support file links (neither hard nor soft links) or >> referencing parent directories via "..", minimizing the risk that >> a guest can "escape" from its home directory >> >> Note that for now the daemon only contains the minimal needed >> functionality to do logging from Xenstore-stubdom. I didn't want to >> add all the 9pfs commands and security add-ons in the beginning, in >> order to avoid needless efforts in case the idea of the daemon is >> being rejected. >> >> Changes in V4: >> - patch 2 of V3 was applied >> - added support of reading directories >> - addressed review comments >> >> Changes in V3: >> - new patches 1, 23-25 >> - addressed review comments >> >> Changes in V2: >> - support of multiple rings per device >> - xenlogd->xen-9pfsd rename >> - addressed review comments >> - fixed some bugs >> >> Juergen Gross (32): >> tools: add access macros for unaligned data >> tools: add a new xen logging daemon >> tools/xen-9pfsd: connect to frontend >> tools/xen-9pfsd: add transport layer >> tools/xen-9pfsd: add 9pfs response generation support >> tools/xen-9pfsd: add 9pfs version request support >> tools/xen-9pfsd: add 9pfs attach request support >> tools/xen-9pfsd: add 9pfs walk request support >> tools/xen-9pfsd: add 9pfs open request support >> tools/xen-9pfsd: add 9pfs clunk request support >> tools/xen-9pfsd: add 9pfs create request support >> tools/xen-9pfsd: add 9pfs stat request support >> tools/xen-9pfsd: add 9pfs write request support >> tools/xen-9pfsd: add 9pfs read request support >> tools/libs/light: add backend type for 9pfs PV devices >> tools/xl: support new 9pfs backend xen_9pfsd >> tools/helpers: allocate xenstore event channel for xenstore stubdom >> tools/xenstored: rename xenbus_evtchn() >> stubdom: extend xenstore stubdom configs >> tools: add 9pfs device to xenstore-stubdom >> tools/xenstored: add early_init() function >> tools/xenstored: move systemd handling to posix.c >> tools/xenstored: move all log-pipe handling into posix.c >> tools/xenstored: move all socket handling into posix.c >> tools/xenstored: get own domid in stubdom case >> tools/xenstored: rework ring page (un)map functions >> tools/xenstored: split domain_init() >> tools/xenstored: map stubdom interface >> tools/xenstored: mount 9pfs device in stubdom >> tools/xenstored: add helpers for filename handling >> tools/xenstored: support complete log capabilities in stubdom >> tools/xenstored: have a single do_control_memreport() > > I haven't checked what's the state of the 9PFS patches. Can part of the > xenstored changes be committed without the 9PFS changes? The following patches can go in without the 9pfs daemon: tools/helpers: allocate xenstore event channel for xenstore stubdom tools/xenstored: rename xenbus_evtchn() stubdom: extend xenstore stubdom configs tools/xenstored: add early_init() function tools/xenstored: move systemd handling to posix.c tools/xenstored: move all log-pipe handling into posix.c tools/xenstored: move all socket handling into posix.c tools/xenstored: get own domid in stubdom case tools/xenstored: rework ring page (un)map functions tools/xenstored: split domain_init() tools/xenstored: map stubdom interface Juergen
Hi Juergen, On 05/02/2024 11:08, Jürgen Groß wrote: > On 05.02.24 11:55, Julien Grall wrote: >> Hi Juergen, >> >> On 05/02/2024 10:49, Juergen Gross wrote: >>> This series is adding 9pfs support to Xenstore-stubdom, enabling it >>> to do logging to a dom0 directory. >>> >>> This is a prerequisite for the final goal to add live update support >>> to Xenstore-stubdom, as it enables the stubdom to store its state in >>> a dom0 file. >>> >>> The 9pfs backend is a new daemon written from scratch. Using a >>> dedicated 9pfs daemon has several advantages: >>> >>> - it is using much less resources than a full blown qemu process >>> - it can serve multiple guests (the idea is to use it for other >>> infrastructure domains, like qemu-stubdom or driver domains, too) >>> - it is designed to support several security enhancements, like >>> limiting the number of files for a guest, or limiting the allocated >>> file system space >>> - it doesn't support file links (neither hard nor soft links) or >>> referencing parent directories via "..", minimizing the risk that >>> a guest can "escape" from its home directory >>> >>> Note that for now the daemon only contains the minimal needed >>> functionality to do logging from Xenstore-stubdom. I didn't want to >>> add all the 9pfs commands and security add-ons in the beginning, in >>> order to avoid needless efforts in case the idea of the daemon is >>> being rejected. >>> >>> Changes in V4: >>> - patch 2 of V3 was applied >>> - added support of reading directories >>> - addressed review comments >>> >>> Changes in V3: >>> - new patches 1, 23-25 >>> - addressed review comments >>> >>> Changes in V2: >>> - support of multiple rings per device >>> - xenlogd->xen-9pfsd rename >>> - addressed review comments >>> - fixed some bugs >>> >>> Juergen Gross (32): >>> tools: add access macros for unaligned data >>> tools: add a new xen logging daemon >>> tools/xen-9pfsd: connect to frontend >>> tools/xen-9pfsd: add transport layer >>> tools/xen-9pfsd: add 9pfs response generation support >>> tools/xen-9pfsd: add 9pfs version request support >>> tools/xen-9pfsd: add 9pfs attach request support >>> tools/xen-9pfsd: add 9pfs walk request support >>> tools/xen-9pfsd: add 9pfs open request support >>> tools/xen-9pfsd: add 9pfs clunk request support >>> tools/xen-9pfsd: add 9pfs create request support >>> tools/xen-9pfsd: add 9pfs stat request support >>> tools/xen-9pfsd: add 9pfs write request support >>> tools/xen-9pfsd: add 9pfs read request support >>> tools/libs/light: add backend type for 9pfs PV devices >>> tools/xl: support new 9pfs backend xen_9pfsd >>> tools/helpers: allocate xenstore event channel for xenstore stubdom >>> tools/xenstored: rename xenbus_evtchn() >>> stubdom: extend xenstore stubdom configs >>> tools: add 9pfs device to xenstore-stubdom >>> tools/xenstored: add early_init() function >>> tools/xenstored: move systemd handling to posix.c >>> tools/xenstored: move all log-pipe handling into posix.c >>> tools/xenstored: move all socket handling into posix.c >>> tools/xenstored: get own domid in stubdom case >>> tools/xenstored: rework ring page (un)map functions >>> tools/xenstored: split domain_init() >>> tools/xenstored: map stubdom interface >>> tools/xenstored: mount 9pfs device in stubdom >>> tools/xenstored: add helpers for filename handling >>> tools/xenstored: support complete log capabilities in stubdom >>> tools/xenstored: have a single do_control_memreport() >> >> I haven't checked what's the state of the 9PFS patches. Can part of >> the xenstored changes be committed without the 9PFS changes? > > The following patches can go in without the 9pfs daemon: It looks like the gitalb CI is not happy with the following patches [1]: In function ‘free_stat’, inlined from ‘write_9pfs’ at 9pfront.c:935:9: 9pfront.c:120:14: error: ‘stat.name’ may be used uninitialized [-Werror=maybe-uninitialized] 120 | free(stat->name); | ~~~~^~~~~~ 9pfront.c: In function ‘write_9pfs’: 9pfront.c:929:20: note: ‘stat’ declared here 929 | struct p9_stat stat; | ^~~~ I think... > > tools/helpers: allocate xenstore event channel for xenstore stubdom > tools/xenstored: rename xenbus_evtchn() > stubdom: extend xenstore stubdom configs .. this is related to this patch. Can you have a look? I have just pushed a new branch without this patch. Let see if the CI [2] will pass this time. > tools/xenstored: add early_init() function > tools/xenstored: move systemd handling to posix.c > tools/xenstored: move all log-pipe handling into posix.c > tools/xenstored: move all socket handling into posix.c > tools/xenstored: get own domid in stubdom case > tools/xenstored: rework ring page (un)map functions > tools/xenstored: split domain_init() > tools/xenstored: map stubdom interface Cheers, [1] https://gitlab.com/xen-project/people/julieng/xen/-/pipelines/1165147815 [2] https://gitlab.com/xen-project/people/julieng/xen/-/pipelines/1165166977
On 05/02/2024 17:18, Julien Grall wrote: > Hi Juergen, > > On 05/02/2024 11:08, Jürgen Groß wrote: >> On 05.02.24 11:55, Julien Grall wrote: >>> Hi Juergen, >>> >>> On 05/02/2024 10:49, Juergen Gross wrote: >>>> This series is adding 9pfs support to Xenstore-stubdom, enabling it >>>> to do logging to a dom0 directory. >>>> >>>> This is a prerequisite for the final goal to add live update support >>>> to Xenstore-stubdom, as it enables the stubdom to store its state in >>>> a dom0 file. >>>> >>>> The 9pfs backend is a new daemon written from scratch. Using a >>>> dedicated 9pfs daemon has several advantages: >>>> >>>> - it is using much less resources than a full blown qemu process >>>> - it can serve multiple guests (the idea is to use it for other >>>> infrastructure domains, like qemu-stubdom or driver domains, too) >>>> - it is designed to support several security enhancements, like >>>> limiting the number of files for a guest, or limiting the allocated >>>> file system space >>>> - it doesn't support file links (neither hard nor soft links) or >>>> referencing parent directories via "..", minimizing the risk that >>>> a guest can "escape" from its home directory >>>> >>>> Note that for now the daemon only contains the minimal needed >>>> functionality to do logging from Xenstore-stubdom. I didn't want to >>>> add all the 9pfs commands and security add-ons in the beginning, in >>>> order to avoid needless efforts in case the idea of the daemon is >>>> being rejected. >>>> >>>> Changes in V4: >>>> - patch 2 of V3 was applied >>>> - added support of reading directories >>>> - addressed review comments >>>> >>>> Changes in V3: >>>> - new patches 1, 23-25 >>>> - addressed review comments >>>> >>>> Changes in V2: >>>> - support of multiple rings per device >>>> - xenlogd->xen-9pfsd rename >>>> - addressed review comments >>>> - fixed some bugs >>>> >>>> Juergen Gross (32): >>>> tools: add access macros for unaligned data >>>> tools: add a new xen logging daemon >>>> tools/xen-9pfsd: connect to frontend >>>> tools/xen-9pfsd: add transport layer >>>> tools/xen-9pfsd: add 9pfs response generation support >>>> tools/xen-9pfsd: add 9pfs version request support >>>> tools/xen-9pfsd: add 9pfs attach request support >>>> tools/xen-9pfsd: add 9pfs walk request support >>>> tools/xen-9pfsd: add 9pfs open request support >>>> tools/xen-9pfsd: add 9pfs clunk request support >>>> tools/xen-9pfsd: add 9pfs create request support >>>> tools/xen-9pfsd: add 9pfs stat request support >>>> tools/xen-9pfsd: add 9pfs write request support >>>> tools/xen-9pfsd: add 9pfs read request support >>>> tools/libs/light: add backend type for 9pfs PV devices >>>> tools/xl: support new 9pfs backend xen_9pfsd >>>> tools/helpers: allocate xenstore event channel for xenstore stubdom >>>> tools/xenstored: rename xenbus_evtchn() >>>> stubdom: extend xenstore stubdom configs >>>> tools: add 9pfs device to xenstore-stubdom >>>> tools/xenstored: add early_init() function >>>> tools/xenstored: move systemd handling to posix.c >>>> tools/xenstored: move all log-pipe handling into posix.c >>>> tools/xenstored: move all socket handling into posix.c >>>> tools/xenstored: get own domid in stubdom case >>>> tools/xenstored: rework ring page (un)map functions >>>> tools/xenstored: split domain_init() >>>> tools/xenstored: map stubdom interface >>>> tools/xenstored: mount 9pfs device in stubdom >>>> tools/xenstored: add helpers for filename handling >>>> tools/xenstored: support complete log capabilities in stubdom >>>> tools/xenstored: have a single do_control_memreport() >>> >>> I haven't checked what's the state of the 9PFS patches. Can part of >>> the xenstored changes be committed without the 9PFS changes? >> >> The following patches can go in without the 9pfs daemon: > > It looks like the gitalb CI is not happy with the following patches [1]: > > In function ‘free_stat’, > inlined from ‘write_9pfs’ at 9pfront.c:935:9: > 9pfront.c:120:14: error: ‘stat.name’ may be used uninitialized > [-Werror=maybe-uninitialized] > 120 | free(stat->name); > | ~~~~^~~~~~ > 9pfront.c: In function ‘write_9pfs’: > 9pfront.c:929:20: note: ‘stat’ declared here > 929 | struct p9_stat stat; > | ^~~~ > > I think... > >> >> tools/helpers: allocate xenstore event channel for xenstore stubdom >> tools/xenstored: rename xenbus_evtchn() >> stubdom: extend xenstore stubdom configs > > .. this is related to this patch. Can you have a look? > > I have just pushed a new branch without this patch. Let see if the CI > [2] will pass this time. It passed. So I committed all the patches you mentionned but "stubdom: extend xenstore stubdom configs". Cheers,