mbox series

[v4,00/32] tools: enable xenstore-stubdom to use 9pfs

Message ID 20240205105001.24171-1-jgross@suse.com (mailing list archive)
Headers show
Series tools: enable xenstore-stubdom to use 9pfs | expand

Message

Jürgen Groß Feb. 5, 2024, 10:49 a.m. UTC
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()

 docs/man/xl.cfg.5.pod.in                      |   36 +-
 stubdom/xenstore-minios.cfg                   |    2 +-
 stubdom/xenstorepvh-minios.cfg                |    2 +-
 tools/Makefile                                |    1 +
 tools/golang/xenlight/helpers.gen.go          |   16 +
 tools/golang/xenlight/types.gen.go            |   13 +
 tools/helpers/init-xenstore-domain.c          |   14 +
 .../Linux/init.d/sysconfig.xencommons.in      |    1 -
 tools/hotplug/Linux/launch-xenstore.in        |    1 +
 tools/include/libxl.h                         |   22 +
 tools/include/xen-tools/common-macros.h       |   17 +
 tools/libs/light/libxl_9pfs.c                 |  193 ++-
 tools/libs/light/libxl_create.c               |    4 +-
 tools/libs/light/libxl_dm.c                   |    2 +-
 tools/libs/light/libxl_types.idl              |   11 +
 tools/libs/light/libxl_types_internal.idl     |    1 +
 tools/xen-9pfsd/.gitignore                    |    1 +
 tools/xen-9pfsd/Makefile                      |   38 +
 tools/xen-9pfsd/io.c                          | 1510 +++++++++++++++++
 tools/xen-9pfsd/xen-9pfsd.c                   |  800 +++++++++
 tools/xen-9pfsd/xen-9pfsd.h                   |   99 ++
 tools/xenstored/Makefile.common               |    4 -
 tools/xenstored/control.c                     |   29 +-
 tools/xenstored/core.c                        |  274 +--
 tools/xenstored/core.h                        |   36 +-
 tools/xenstored/domain.c                      |   81 +-
 tools/xenstored/domain.h                      |    2 +
 tools/xenstored/lu_daemon.c                   |    4 +-
 tools/xenstored/minios.c                      |  102 +-
 tools/xenstored/posix.c                       |  263 ++-
 tools/xl/xl_parse.c                           |   23 +-
 31 files changed, 3261 insertions(+), 341 deletions(-)
 create mode 100644 tools/xen-9pfsd/.gitignore
 create mode 100644 tools/xen-9pfsd/Makefile
 create mode 100644 tools/xen-9pfsd/io.c
 create mode 100644 tools/xen-9pfsd/xen-9pfsd.c
 create mode 100644 tools/xen-9pfsd/xen-9pfsd.h

Comments

Julien Grall Feb. 5, 2024, 10:55 a.m. UTC | #1
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,
Jürgen Groß Feb. 5, 2024, 11:08 a.m. UTC | #2
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
Julien Grall Feb. 5, 2024, 5:18 p.m. UTC | #3
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
Julien Grall Feb. 5, 2024, 9:13 p.m. UTC | #4
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,