Re: [PATCH RFC 01/15] xen: allow console_io hypercalls from DomUs on ARM

Re: [PATCH RFC 01/15] xen: allow console_io hypercalls from DomUs on ARM

[DeGraaf, Daniel G]

-----Original Message-----
> On 13/06/18 23:15, Stefano Stabellini wrote:
> > This is very useful when starting multiple domains from Xen without
> > xenstore access. It will allow them to print out to the Xen console.
> >
> > Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
> > CC: andrew.cooper3@citrix.com
> > CC: George.Dunlap@eu.citrix.com
> > CC: ian.jackson@eu.citrix.com
> > CC: jbeulich@suse.com
> > CC: konrad.wilk@oracle.com
> > CC: tim@xen.org
> > CC: wei.liu2@citrix.com
> > CC: dgdegra@tycho.nsa.gov
> > ---
> > If there is a better way to do this with XSM, please advise.
> 
> We definitely need to keep the XSM around to avoid opening a hole. We also don't want all the domain to access the console.
> 
> Looking at the implementation, any domain with is_privileged will be able to access the console. IHMO, I don't think we should set
> that for DomU created by Xen.
> 
> So I would suggest to introduce a new variable is_console and to tell whether a domain can access the console. xsm_console_io(...)
> would then need to be updated accordingly.

There is an existing CONFIG_VERBOSE_DEBUG option which, among other things, allows console output from any domain.  The console output part of that (which is just the #ifdef in include/xsm/dummy.h) could be moved to another CONFIG or ORed with an ARM flag. This would apply to all domains; if that's not what you want, you'll need to add a flag (like Julien suggested) or use XSM.

If XSM is enabled, guest hypervisor console output is controlled by the guest_writeconsole boolean in the default policy (tools/flask/policy/modules/guest_features.te) which defaults to allowing it.


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

Re: [PATCH RFC 01/15] xen: allow console_io hypercalls from DomUs on ARM

[Stefano Stabellini]

On Thu, 14 Jun 2018, DeGraaf, Daniel G wrote:
> -----Original Message-----
> > On 13/06/18 23:15, Stefano Stabellini wrote:
> > > This is very useful when starting multiple domains from Xen without
> > > xenstore access. It will allow them to print out to the Xen console.
> > >
> > > Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
> > > CC: andrew.cooper3@citrix.com
> > > CC: George.Dunlap@eu.citrix.com
> > > CC: ian.jackson@eu.citrix.com
> > > CC: jbeulich@suse.com
> > > CC: konrad.wilk@oracle.com
> > > CC: tim@xen.org
> > > CC: wei.liu2@citrix.com
> > > CC: dgdegra@tycho.nsa.gov
> > > ---
> > > If there is a better way to do this with XSM, please advise.
> > 
> > We definitely need to keep the XSM around to avoid opening a hole. We also don't want all the domain to access the console.
> > 
> > Looking at the implementation, any domain with is_privileged will be able to access the console. IHMO, I don't think we should set
> > that for DomU created by Xen.
> > 
> > So I would suggest to introduce a new variable is_console and to tell whether a domain can access the console. xsm_console_io(...)
> > would then need to be updated accordingly.
> 
> There is an existing CONFIG_VERBOSE_DEBUG option which, among other things, allows console output from any domain.  The console output part of that (which is just the #ifdef in include/xsm/dummy.h) could be moved to another CONFIG or ORed with an ARM flag. This would apply to all domains; if that's not what you want, you'll need to add a flag (like Julien suggested) or use XSM.
> 
> If XSM is enabled, guest hypervisor console output is controlled by the guest_writeconsole boolean in the default policy (tools/flask/policy/modules/guest_features.te) which defaults to allowing it.

I think the best user experience would be:
- do not to require XSM to be enabled
- do not to allow all domains to use the Xen console, only the ones started
  from Xen
- domUs started from Xen should not be is_privileged

Indeed, the best approach would be be to add a new is_console option.

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

[PATCH RFC 00/15] dom0less step1: boot multiple domains from device tree

[Stefano Stabellini]

Hi all,

This is first step toward "dom0less" as discussed in the various
certifications related threads and discussions.

The goal of this series is to enable Xen to boot multiple domains in
parallel, in addition to dom0, out of information found on device tree.

The device tree based boot protocol is extended to carry information
about DomUs. Based on that information, Xen creates and starts one or
more DomUs. DomUs created this way don't have access to xenstore, as
xenstore is not started yet. This is actually OK, because this is meant
for mission critical applications that typically only access directly
assigned devices. They cannot tolerate interference or increased IRQ
latency due to PV protocols. Device assignment is not actually covered
by this series, it will be added later.

DomUs can print to the Xen serial using the CONSOLEIO hypercalls. A
virtual PL011 is also emulated for them so that they can use their
regular PL011 driver. This allows unmodified guests to run as Xen on ARM
guests -- no Xen support needed at all. Console input also comes from
the Xen serial: the Ctrl-AAA switching mechanism is extended to switch
among domUs, dom0, and Xen.

Cheers,

Stefano


Stefano Stabellini (15):
      xen: allow console_io hypercalls from DomUs on ARM
      xen/arm: move a few guest related #defines to public/arch-arm.h
      xen/arm: extend device tree based multiboot protocol
      xen/arm: do not pass dt_host to make_memory_node and make_hypervisor_node
      xen/arm: rename acpi_make_chosen_node to make_chosen_node
      xen/arm: add BOOTMOD_DOMU_KERNEL/RAMDISK
      xen/arm: increase MAX_MODULES
      xen/arm: probe domU kernels and initrds
      xen/arm: refactor construct_dom0
      xen/arm: introduce construct_domU
      xen/arm: generate a simple device tree for domUs
      xen/arm: generate vpl011 node on device tree for domU
      xen/arm: Allow vpl011 to be used by DomU
      xen/arm: call construct_domU from start_xen and start DomU VMs
      xen: support console_switching between Dom0 and DomUs on ARM

 docs/misc/arm/device-tree/booting.txt | 102 +++++++
 tools/libxl/libxl_arm.c               |  26 --
 xen/arch/arm/bootfdt.c                |   4 +
 xen/arch/arm/domain_build.c           | 533 +++++++++++++++++++++++++++-------
 xen/arch/arm/kernel.c                 |  54 ++++
 xen/arch/arm/kernel.h                 |   2 +
 xen/arch/arm/setup.c                  |  52 +++-
 xen/arch/arm/vpl011.c                 |  98 +++++--
 xen/common/device_tree.c              |   6 +-
 xen/drivers/char/console.c            |  51 +++-
 xen/include/asm-arm/setup.h           |  10 +-
 xen/include/asm-arm/vpl011.h          |   2 +
 xen/include/asm-x86/setup.h           |   2 +
 xen/include/public/arch-arm.h         |  26 ++
 xen/include/xen/device_tree.h         |   2 +-
 15 files changed, 789 insertions(+), 181 deletions(-)

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

[PATCH RFC 01/15] xen: allow console_io hypercalls from DomUs on ARM

[Stefano Stabellini]

This is very useful when starting multiple domains from Xen without
xenstore access. It will allow them to print out to the Xen console.

Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
CC: andrew.cooper3@citrix.com
CC: George.Dunlap@eu.citrix.com
CC: ian.jackson@eu.citrix.com
CC: jbeulich@suse.com
CC: konrad.wilk@oracle.com
CC: tim@xen.org
CC: wei.liu2@citrix.com
CC: dgdegra@tycho.nsa.gov
---
If there is a better way to do this with XSM, please advise.

---
 xen/drivers/char/console.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 0f05369..dc9e0bb 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -555,9 +555,11 @@ long do_console_io(int cmd, int count, XEN_GUEST_HANDLE_PARAM(char) buffer)
     long rc;
     unsigned int idx, len;
 
+#ifndef CONFIG_ARM
     rc = xsm_console_io(XSM_OTHER, current->domain, cmd);
     if ( rc )
         return rc;
+#endif
 
     switch ( cmd )
     {
-- 
1.9.1


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

Re: [PATCH RFC 01/15] xen: allow console_io hypercalls from DomUs on ARM

[Julien Grall]

Hi Stefano,

On 13/06/18 23:15, Stefano Stabellini wrote:
> This is very useful when starting multiple domains from Xen without
> xenstore access. It will allow them to print out to the Xen console.
> 
> Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
> CC: andrew.cooper3@citrix.com
> CC: George.Dunlap@eu.citrix.com
> CC: ian.jackson@eu.citrix.com
> CC: jbeulich@suse.com
> CC: konrad.wilk@oracle.com
> CC: tim@xen.org
> CC: wei.liu2@citrix.com
> CC: dgdegra@tycho.nsa.gov
> ---
> If there is a better way to do this with XSM, please advise.

We definitely need to keep the XSM around to avoid opening a hole. We 
also don't want all the domain to access the console.

Looking at the implementation, any domain with is_privileged will be 
able to access the console. IHMO, I don't think we should set that for 
DomU created by Xen.

So I would suggest to introduce a new variable is_console and to tell 
whether a domain can access the console. xsm_console_io(...) would then 
need to be updated accordingly.

Cheers,

-- 
Julien Grall

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