| Message ID | 20241217114719.2870676-1-Sergiy_Kibrik@epam.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] xen/kconfig: allow LATE_HWDOM config for ARM | expand |
Hi, Can you clarify why this is an RFC? On 17/12/2024 11:47, Sergiy Kibrik wrote: > Allow to build ARM configuration with support for initializing hardware domain. > On ARM it is only possible to start hardware domain in multiboot mode, so > dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT > instead of directly depending on ARM config option. I am a bit confused with the explanation. We already have an hardware domain on Arm. It is dom0. So what are you trying to achieve? Is this remove some permissions from the hardware domain? If so, why can't the hardware domain stay as dom0 and you remove the feature you don't want (e.g. control domain)? Are you sure this patch is sufficient to use the late hwdom feature? Looking at the code, to enable the late hwdom, the user needs to provide a domid on the command line. But AFAICT, there is no way to provide a domain ID in the DOM0LESS case... > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> > --- > xen/common/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 90268d9249..7368ca8208 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -374,7 +374,7 @@ endchoice > config LATE_HWDOM > bool "Dedicated hardware domain" > default n > - depends on XSM && X86 > + depends on XSM && (X86 || DOM0LESS_BOOT) This will enable LATE_HWDOM for other arch. Is this what we want? > help > Allows the creation of a dedicated hardware domain distinct from > domain 0 that manages devices without needing access to other Cheers,
On 17.12.2024 12:47, Sergiy Kibrik wrote: > Allow to build ARM configuration with support for initializing hardware domain. > On ARM it is only possible to start hardware domain in multiboot mode, so > dom0less support is required. I don't follow this. Late hwdom is supposed to be started by a (minimal) toolstack iirc. Jan
> On 17/12/2024 11:47, Sergiy Kibrik wrote: >> Allow to build ARM configuration with support for initializing >> hardware domain. >> On ARM it is only possible to start hardware domain in multiboot mode, so >> dom0less support is required. This is reflected by dependency on >> DOM0LESS_BOOT >> instead of directly depending on ARM config option. Just to make sure my assumption is correct, you are looking to do a multi-domain construction at boot time, with at least two domains. One of those two domains is the "control domain" and one is the "hardware domain", aka late hwdom except it's not constructed "late". If you want such a configuration, I would highly recommend you first enable setting flask labels via dom0less (assuming it is not there) before lighting this feature up. This is because the dummy/base policy has no support for differentiating between a "control domain" and a "hardware domain". What you really would end up with is two control domains, with one also having control over hardware. v/r dps
hi Julien, 17.12.24 14:42, Julien Grall: > Hi, > > Can you clarify why this is an RFC? > The code for LATE_HWDOM support on ARM seems to be already in place and working, yet I'm not sure that such configuration is ready to be exposed for users (well, probably not ready yet, considering Daniel's comments regarding XSM later in this thread). > On 17/12/2024 11:47, Sergiy Kibrik wrote: >> Allow to build ARM configuration with support for initializing >> hardware domain. >> On ARM it is only possible to start hardware domain in multiboot mode, so >> dom0less support is required. This is reflected by dependency on >> DOM0LESS_BOOT >> instead of directly depending on ARM config option. > > I am a bit confused with the explanation. We already have an hardware > domain on Arm. It is dom0. So what are you trying to achieve? Is this > remove some permissions from the hardware domain? I agree, it should have better description. This is to split dom0 permissions into control-only and hardware-only domains, much like it can be done in x86. > > If so, why can't the hardware domain stay as dom0 and you remove the > feature you don't want (e.g. control domain)? control domain is still needed, but as a separate instance & without hardware access. > > Are you sure this patch is sufficient to use the late hwdom feature? > Looking at the code, to enable the late hwdom, the user needs to provide > a domid on the command line. But AFAICT, there is no way to provide a > domain ID in the DOM0LESS case... > I append "hardware_dom=1" to xen,xen-bootargs in host's device tree and it works. >> >> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> >> --- >> xen/common/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/xen/common/Kconfig b/xen/common/Kconfig >> index 90268d9249..7368ca8208 100644 >> --- a/xen/common/Kconfig >> +++ b/xen/common/Kconfig >> @@ -374,7 +374,7 @@ endchoice >> config LATE_HWDOM >> bool "Dedicated hardware domain" >> default n >> - depends on XSM && X86 >> + depends on XSM && (X86 || DOM0LESS_BOOT) > > This will enable LATE_HWDOM for other arch. Is this what we want? my assumption was that DOM0LESS_BOOT only available on ARM, hence other arch won't be affected. -Sergiy
17.12.24 15:02, Jan Beulich: > On 17.12.2024 12:47, Sergiy Kibrik wrote: >> Allow to build ARM configuration with support for initializing hardware domain. >> On ARM it is only possible to start hardware domain in multiboot mode, so >> dom0less support is required. > > I don't follow this. Late hwdom is supposed to be started by a (minimal) > toolstack iirc. Yes, on x86 it's started by toolstack. This is not supported on ARM. However dom0less can already handle hardware domain initialization on ARM, without much of an additional changes. -Sergiy
18.12.24 03:17, Daniel P. Smith: >> On 17/12/2024 11:47, Sergiy Kibrik wrote: >>> Allow to build ARM configuration with support for initializing >>> hardware domain. >>> On ARM it is only possible to start hardware domain in multiboot >>> mode, so >>> dom0less support is required. This is reflected by dependency on >>> DOM0LESS_BOOT >>> instead of directly depending on ARM config option. > > > Just to make sure my assumption is correct, you are looking to do a > multi-domain construction at boot time, with at least two domains. One > of those two domains is the "control domain" and one is the "hardware > domain", aka late hwdom except it's not constructed "late". yes, you're correct > > If you want such a configuration, I would highly recommend you first > enable setting flask labels via dom0less (assuming it is not there) > before lighting this feature up. This is because the dummy/base policy > has no support for differentiating between a "control domain" and a > "hardware domain". What you really would end up with is two control > domains, with one also having control over hardware. > will check this out, thank you for suggestion! -Sergiy
On 18/12/2024 09:52, Sergiy Kibrik wrote: > hi Julien, > > 17.12.24 14:42, Julien Grall: >> Hi, >> >> Can you clarify why this is an RFC? >> > > The code for LATE_HWDOM support on ARM seems to be already in place and > working, yet I'm not sure that such configuration is ready to be exposed > for users (well, probably not ready yet, considering Daniel's comments > regarding XSM later in this thread). Thanks. In the future, for RFCs, I would suggest to add a section after your commit message (generally after ---) to describe a bit more what you input you expect from the reviewers. > > >> On 17/12/2024 11:47, Sergiy Kibrik wrote: >>> Allow to build ARM configuration with support for initializing >>> hardware domain. >>> On ARM it is only possible to start hardware domain in multiboot >>> mode, so >>> dom0less support is required. This is reflected by dependency on >>> DOM0LESS_BOOT >>> instead of directly depending on ARM config option. >> >> I am a bit confused with the explanation. We already have an hardware >> domain on Arm. It is dom0. So what are you trying to achieve? Is this >> remove some permissions from the hardware domain? > > I agree, it should have better description. > This is to split dom0 permissions into control-only and hardware-only > domains, much like it can be done in x86. I don't believe you need the late_hwdom feature to do that on Arm. In the case of dom0less, you are creating the domains at boot, so at the point you can decide who does what. You don't need to transfer the permissions (which seems odd in the context of dom0less) to a new domain after dom0 is created. > >> >> If so, why can't the hardware domain stay as dom0 and you remove the >> feature you don't want (e.g. control domain)? > > control domain is still needed, but as a separate instance & without > hardware access. Sure. But the control domain doesn't need to be dom0, it could be dom1, right? > >> >> Are you sure this patch is sufficient to use the late hwdom feature? >> Looking at the code, to enable the late hwdom, the user needs to >> provide a domid on the command line. But AFAICT, there is no way to >> provide a domain ID in the DOM0LESS case... >> > > I append "hardware_dom=1" to xen,xen-bootargs in host's device tree and > it works. AFAIU, the domain needs to be explicitely created. How do you do that? Is it just describing the domain in the DT? If so, how does it work if there are multiple domain described in the DT? > >>> >>> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> >>> --- >>> xen/common/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig >>> index 90268d9249..7368ca8208 100644 >>> --- a/xen/common/Kconfig >>> +++ b/xen/common/Kconfig >>> @@ -374,7 +374,7 @@ endchoice >>> config LATE_HWDOM >>> bool "Dedicated hardware domain" >>> default n >>> - depends on XSM && X86 >>> + depends on XSM && (X86 || DOM0LESS_BOOT) >> >> This will enable LATE_HWDOM for other arch. Is this what we want? > > my assumption was that DOM0LESS_BOOT only available on ARM, hence other > arch won't be affected. Well... There are effort to support dom0less_boot on other architectures. But to be honest, I am not convinced that we should enable LATE_HWDOM here. Cheers,
On 17/12/2024 11:47 am, Sergiy Kibrik wrote: > Allow to build ARM configuration with support for initializing hardware domain. > On ARM it is only possible to start hardware domain in multiboot mode, so > dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT > instead of directly depending on ARM config option. > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> > --- > xen/common/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 90268d9249..7368ca8208 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -374,7 +374,7 @@ endchoice > config LATE_HWDOM > bool "Dedicated hardware domain" > default n > - depends on XSM && X86 > + depends on XSM && (X86 || DOM0LESS_BOOT) > help > Allows the creation of a dedicated hardware domain distinct from > domain 0 that manages devices without needing access to other To ask a questions not asked elsewhere on this thread. We are expecting Hyperlaunch to supersede and entirely replace what is currently x86's idea of split control/hwdom, to this point where this symbol is even removed. Has this plan changed? ~Andrew
On 18/12/2024 10:05, Julien Grall wrote: > > > On 18/12/2024 09:52, Sergiy Kibrik wrote: >> hi Julien, >> >> 17.12.24 14:42, Julien Grall: >>> Hi, >>> >>> Can you clarify why this is an RFC? >>> >> >> The code for LATE_HWDOM support on ARM seems to be already in place >> and working, yet I'm not sure that such configuration is ready to be >> exposed for users (well, probably not ready yet, considering Daniel's >> comments regarding XSM later in this thread). > > Thanks. In the future, for RFCs, I would suggest to add a section after > your commit message (generally after ---) to describe a bit more what > you input you expect from the reviewers. > >> >> >>> On 17/12/2024 11:47, Sergiy Kibrik wrote: >>>> Allow to build ARM configuration with support for initializing >>>> hardware domain. >>>> On ARM it is only possible to start hardware domain in multiboot >>>> mode, so >>>> dom0less support is required. This is reflected by dependency on >>>> DOM0LESS_BOOT >>>> instead of directly depending on ARM config option. >>> >>> I am a bit confused with the explanation. We already have an hardware >>> domain on Arm. It is dom0. So what are you trying to achieve? Is this >>> remove some permissions from the hardware domain? >> >> I agree, it should have better description. >> This is to split dom0 permissions into control-only and hardware-only >> domains, much like it can be done in x86. > > I don't believe you need the late_hwdom feature to do that on Arm. In > the case of dom0less, you are creating the domains at boot, so at the > point you can decide who does what. > > You don't need to transfer the permissions (which seems odd in the > context of dom0less) to a new domain after dom0 is created. > >> >>> >>> If so, why can't the hardware domain stay as dom0 and you remove the >>> feature you don't want (e.g. control domain)? >> >> control domain is still needed, but as a separate instance & without >> hardware access. > > Sure. But the control domain doesn't need to be dom0, it could be dom1, > right? > >> >>> >>> Are you sure this patch is sufficient to use the late hwdom feature? >>> Looking at the code, to enable the late hwdom, the user needs to >>> provide a domid on the command line. But AFAICT, there is no way to >>> provide a domain ID in the DOM0LESS case... >>> >> >> I append "hardware_dom=1" to xen,xen-bootargs in host's device tree >> and it works. > > AFAIU, the domain needs to be explicitely created. How do you do that? > Is it just describing the domain in the DT? If so, how does it work if > there are multiple domain described in the DT? I just had a look at the code. I don't see how this change and simply adding "hardware_dom=X" is sufficient. In addition to what I wrote above, Dom0 will be the first domain created and we will assign all the devices and mappings. When the hardware domain is created later on, dom0 will still have those mappings and devices. That's unless you list all the devices in the device-tree as not assigned to dom0 and then assign them manually to the hardware domain. I would also expect that the hardware domain wants to use the same memory layout as the host. But that's not necessary for the control domain. So surely you need something more in the device-tree? Cheers,
Hi Daniel, On 18/12/2024 02:17, Daniel P. Smith wrote: > > >> On 17/12/2024 11:47, Sergiy Kibrik wrote: >>> Allow to build ARM configuration with support for initializing >>> hardware domain. >>> On ARM it is only possible to start hardware domain in multiboot mode, so >>> dom0less support is required. This is reflected by dependency on >>> DOM0LESS_BOOT >>> instead of directly depending on ARM config option. > > > Just to make sure my assumption is correct, you are looking to do a > multi-domain construction at boot time, with at least two domains. One > of those two domains is the "control domain" and one is the "hardware > domain", aka late hwdom except it's not constructed "late". > > If you want such a configuration, I would highly recommend you first > enable setting flask labels via dom0less (assuming it is not there) Speaking about dom0less and FLASK. A year ago, I did sent you (privately, through AMD hyperlaunch collab) my attempt to add minimal steps to enable setting FLASK policy for dom0less domUs. You then told me that you have a slightly different vision on how it should be done. Any update with that regard? TBH I though that you're going to add this support together with other hyperlaunch patches. For others reference, I attach my patch created back then allowing to specify FLASK labels for boot-time domUs, which I used to assign different FLASK roles for them. ~Michal From fae75e940641d1248d2cffde9ed568f121a755f5 Mon Sep 17 00:00:00 2001 From: Michal Orzel <michal.orzel@amd.com> Date: Tue, 12 Mar 2024 13:03:42 +0100 Subject: [PATCH] xen: Add support for specifying XSM FLASK label for dom0less domUs At the moment, it is not possible to create dom0less domUs with XSM FLASK policy (enforcing). This is because they are not being assigned any usable default label (neither in flask_domain_alloc_security() nor by setting initial ssidref in domain creation flags) and as such, they are of type unlabeled_t. Introduce a new XSM op called seclabel_to_sid together with hooks xsm_seclabel_to_sid() and flask_seclabel_to_sid(). In the latter case, this results in calling security_context_to_sid() that converts a security label into SID. Add support for specifying a security label (just like in xl.cfg) for dom0less domUs by adding a new device tree string property 'seclabel'. Signed-off-by: Michal Orzel <michal.orzel@amd.com> --- docs/misc/arm/device-tree/booting.txt | 6 ++++++ xen/arch/arm/dom0less-build.c | 12 ++++++++++++ xen/include/xsm/dummy.h | 6 ++++++ xen/include/xsm/xsm.h | 7 +++++++ xen/xsm/dummy.c | 1 + xen/xsm/flask/hooks.c | 7 +++++++ 6 files changed, 39 insertions(+) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index bbd955e9c2f6..4eba0524ad41 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -260,6 +260,12 @@ with the following properties: value specified by Xen command line parameter gnttab_max_maptrack_frames (or its default value if unspecified, i.e. 1024) is used. +- seclabel + + Optional. A string property specifying XSM FLASK security label for + the domain in format user:role:type (e.g. system_u:system_r:domU_t). + If this property is missing, the domain will be of type unlabeled_t. + Under the "xen,domain" compatible node, one or more sub-nodes are present for the DomU kernel and ramdisk. diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index fb63ec6fd111..b6c762d6ee3d 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -10,6 +10,8 @@ #include <xen/sizes.h> #include <xen/vmap.h> +#include <xsm/xsm.h> + #include <asm/arm64/sve.h> #include <asm/dom0less-build.h> #include <asm/domain_build.h> @@ -869,6 +871,7 @@ void __init create_domUs(void) .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version), }; unsigned int flags = 0U; + const char *seclabel; uint32_t val; int rc; @@ -987,6 +990,15 @@ void __init create_domUs(void) #endif } + if ( !dt_property_read_string(node, "seclabel", &seclabel) ) + { + rc = xsm_seclabel_to_sid(seclabel, strlen(seclabel), + &d_cfg.ssidref); + if ( rc ) + panic("Could not convert seclabel \"%s\" to sid (%d)\n", + seclabel, rc); + } + /* * The variable max_init_domid is initialized with zero, so here it's * very important to use the pre-increment operator to call diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h index 8671af1ba4d3..4b63b6c36241 100644 --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -815,6 +815,12 @@ static XSM_INLINE int cf_check xsm_argo_send( #endif /* CONFIG_ARGO */ +static XSM_INLINE int cf_check xsm_seclabel_to_sid( + const char *seclabel, size_t len, uint32_t *sid) +{ + return -ENOSYS; +} + #include <public/version.h> static XSM_INLINE int cf_check xsm_xen_version(XSM_DEFAULT_ARG uint32_t op) { diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index 8dad03fd3d45..575a141ee26a 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -201,6 +201,7 @@ struct xsm_ops { int (*argo_register_any_source)(const struct domain *d); int (*argo_send)(const struct domain *d, const struct domain *t); #endif + int (*seclabel_to_sid)(const char *seclabel, size_t len, uint32_t *sid); }; #ifdef CONFIG_XSM @@ -774,6 +775,12 @@ static inline int xsm_argo_send(const struct domain *d, const struct domain *t) #endif /* CONFIG_ARGO */ +static inline int xsm_seclabel_to_sid( + const char *seclabel, size_t len, uint32_t *sid) +{ + return alternative_call(xsm_ops.seclabel_to_sid, seclabel, len, sid); +} + #endif /* XSM_NO_WRAPPERS */ #ifdef CONFIG_MULTIBOOT diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c index e6ffa948f7c5..ba1b3def52db 100644 --- a/xen/xsm/dummy.c +++ b/xen/xsm/dummy.c @@ -148,6 +148,7 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = { .argo_register_any_source = xsm_argo_register_any_source, .argo_send = xsm_argo_send, #endif + .seclabel_to_sid = xsm_seclabel_to_sid, }; void __init xsm_fixup_ops(struct xsm_ops *ops) diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index 78225f68c15c..bc1520b4b5dd 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -1838,6 +1838,12 @@ static int cf_check flask_argo_send( #endif +static int cf_check flask_seclabel_to_sid( + const char *seclabel, size_t len, uint32_t *sid) +{ + return security_context_to_sid((char *)seclabel, len, sid); +} + static const struct xsm_ops __initconst_cf_clobber flask_ops = { .set_system_active = flask_set_system_active, .security_domaininfo = flask_security_domaininfo, @@ -1974,6 +1980,7 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = { .argo_register_any_source = flask_argo_register_any_source, .argo_send = flask_argo_send, #endif + .seclabel_to_sid = flask_seclabel_to_sid, }; const struct xsm_ops *__init flask_init(
On 12/18/24 05:04, Sergiy Kibrik wrote: > 18.12.24 03:17, Daniel P. Smith: >>> On 17/12/2024 11:47, Sergiy Kibrik wrote: >>>> Allow to build ARM configuration with support for initializing >>>> hardware domain. >>>> On ARM it is only possible to start hardware domain in multiboot >>>> mode, so >>>> dom0less support is required. This is reflected by dependency on >>>> DOM0LESS_BOOT >>>> instead of directly depending on ARM config option. >> >> >> Just to make sure my assumption is correct, you are looking to do a >> multi-domain construction at boot time, with at least two domains. One >> of those two domains is the "control domain" and one is the "hardware >> domain", aka late hwdom except it's not constructed "late". > > yes, you're correct > >> >> If you want such a configuration, I would highly recommend you first >> enable setting flask labels via dom0less (assuming it is not there) >> before lighting this feature up. This is because the dummy/base policy >> has no support for differentiating between a "control domain" and a >> "hardware domain". What you really would end up with is two control >> domains, with one also having control over hardware. >> > > will check this out, thank you for suggestion! Apologies, one minor correction. You would get a control domain and a domU with the hardware mapped into its address space, not two control domains. I was not thinking about the fact that dom0less builds a single dom0, if defined, and all the domain definitions are built as domU. v/r, dps
On 12/18/24 05:24, Andrew Cooper wrote: > On 17/12/2024 11:47 am, Sergiy Kibrik wrote: >> Allow to build ARM configuration with support for initializing hardware domain. >> On ARM it is only possible to start hardware domain in multiboot mode, so >> dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT >> instead of directly depending on ARM config option. >> >> Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> >> --- >> xen/common/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/xen/common/Kconfig b/xen/common/Kconfig >> index 90268d9249..7368ca8208 100644 >> --- a/xen/common/Kconfig >> +++ b/xen/common/Kconfig >> @@ -374,7 +374,7 @@ endchoice >> config LATE_HWDOM >> bool "Dedicated hardware domain" >> default n >> - depends on XSM && X86 >> + depends on XSM && (X86 || DOM0LESS_BOOT) >> help >> Allows the creation of a dedicated hardware domain distinct from >> domain 0 that manages devices without needing access to other > > To ask a questions not asked elsewhere on this thread. > > We are expecting Hyperlaunch to supersede and entirely replace what is > currently x86's idea of split control/hwdom, to this point where this > symbol is even removed. > > Has this plan changed? In the long term, no. In the short term, the multi-domain builder introduces the means to differentiate, but there is still discussion to be had around how the dummy policy should/would need to be updated. v/r, dps
Hey Michal, On 12/18/24 06:04, Michal Orzel wrote: > Hi Daniel, > > On 18/12/2024 02:17, Daniel P. Smith wrote: >> >> >>> On 17/12/2024 11:47, Sergiy Kibrik wrote: >>>> Allow to build ARM configuration with support for initializing >>>> hardware domain. >>>> On ARM it is only possible to start hardware domain in multiboot mode, so >>>> dom0less support is required. This is reflected by dependency on >>>> DOM0LESS_BOOT >>>> instead of directly depending on ARM config option. >> >> >> Just to make sure my assumption is correct, you are looking to do a >> multi-domain construction at boot time, with at least two domains. One >> of those two domains is the "control domain" and one is the "hardware >> domain", aka late hwdom except it's not constructed "late". >> >> If you want such a configuration, I would highly recommend you first >> enable setting flask labels via dom0less (assuming it is not there) > Speaking about dom0less and FLASK. A year ago, I did sent you (privately, through > AMD hyperlaunch collab) my attempt to add minimal steps to enable setting FLASK policy > for dom0less domUs. You then told me that you have a slightly different vision on how it > should be done. Any update with that regard? TBH I though that you're going to add this > support together with other hyperlaunch patches. As I mentioned back in my March response, the concern I have with the patch you provided was with the layering violation. A security label is a flask-centric concept, at least currently, and thus not a concept you want to expose in the general XSM api. The correct way to get an XSM module's specific info, or translation, is to use the xsm_do_xsm_op(). I do feel that xsm_do_xsm_op() has a laying violation in its implementation, and is what I want to fix, it is still the correct interface. Priorities in meeting the core requirements AMD needs from hyperlaunch resulted in several abilities to fall to the wayside for the time being. I understand things need to move along, so I would prefer the use of existing interface that can be just updated when xsm_do_xsm_op() does get fixed up. v/r, dps
On 18.12.2024 11:00, Sergiy Kibrik wrote: > 17.12.24 15:02, Jan Beulich: >> On 17.12.2024 12:47, Sergiy Kibrik wrote: >>> Allow to build ARM configuration with support for initializing hardware domain. >>> On ARM it is only possible to start hardware domain in multiboot mode, so >>> dom0less support is required. >> >> I don't follow this. Late hwdom is supposed to be started by a (minimal) >> toolstack iirc. > > Yes, on x86 it's started by toolstack. This is not supported on ARM. > However dom0less can already handle hardware domain initialization on > ARM, without much of an additional changes. Yet that's not "late hwdom" then, but "separate hwdom and ctrldom" or some such. Jan
On 18/12/2024 17:26, Daniel P. Smith wrote: > > > Hey Michal, > > On 12/18/24 06:04, Michal Orzel wrote: >> Hi Daniel, >> >> On 18/12/2024 02:17, Daniel P. Smith wrote: >>> >>> >>>> On 17/12/2024 11:47, Sergiy Kibrik wrote: >>>>> Allow to build ARM configuration with support for initializing >>>>> hardware domain. >>>>> On ARM it is only possible to start hardware domain in multiboot mode, so >>>>> dom0less support is required. This is reflected by dependency on >>>>> DOM0LESS_BOOT >>>>> instead of directly depending on ARM config option. >>> >>> >>> Just to make sure my assumption is correct, you are looking to do a >>> multi-domain construction at boot time, with at least two domains. One >>> of those two domains is the "control domain" and one is the "hardware >>> domain", aka late hwdom except it's not constructed "late". >>> >>> If you want such a configuration, I would highly recommend you first >>> enable setting flask labels via dom0less (assuming it is not there) >> Speaking about dom0less and FLASK. A year ago, I did sent you (privately, through >> AMD hyperlaunch collab) my attempt to add minimal steps to enable setting FLASK policy >> for dom0less domUs. You then told me that you have a slightly different vision on how it >> should be done. Any update with that regard? TBH I though that you're going to add this >> support together with other hyperlaunch patches. > > As I mentioned back in my March response, the concern I have with the > patch you provided was with the layering violation. A security label is > a flask-centric concept, at least currently, and thus not a concept you > want to expose in the general XSM api. The correct way to get an XSM > module's specific info, or translation, is to use the xsm_do_xsm_op(). I > do feel that xsm_do_xsm_op() has a laying violation in its > implementation, and is what I want to fix, it is still the correct > interface. Priorities in meeting the core requirements AMD needs from > hyperlaunch resulted in several abilities to fall to the wayside for the > time being. I understand things need to move along, so I would prefer > the use of existing interface that can be just updated when > xsm_do_xsm_op() does get fixed up. xsm_do_xsm_op() is made as an interface between a guest and Xen and is expected to be called from within a guest, just like any other hypercall. In dom0less case, it's Xen who needs to convert seclabel specified by the user to SID. How do you expect Xen to use xsm_do_xsm_op()? ~Michal
diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 90268d9249..7368ca8208 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -374,7 +374,7 @@ endchoice config LATE_HWDOM bool "Dedicated hardware domain" default n - depends on XSM && X86 + depends on XSM && (X86 || DOM0LESS_BOOT) help Allows the creation of a dedicated hardware domain distinct from domain 0 that manages devices without needing access to other
Allow to build ARM configuration with support for initializing hardware domain. On ARM it is only possible to start hardware domain in multiboot mode, so dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT instead of directly depending on ARM config option. Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> --- xen/common/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)