xen/arch/arm/arm64/domctl.c | 46 +++++++++++++++++++++++++++++-- xen/arch/arm/domain.c | 5 ++++ xen/arch/arm/include/asm/domain.h | 1 + 3 files changed, 49 insertions(+), 3 deletions(-)
Signed-off-by: Milan Djokic <milan_djokic@epam.com>
---
XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
It would be useful to have this hypercall supported for arm64, in order to get
current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
performs switch to target addressing mode (instead of relying on its returned error code only).
---
xen/arch/arm/arm64/domctl.c | 46 +++++++++++++++++++++++++++++--
xen/arch/arm/domain.c | 5 ++++
xen/arch/arm/include/asm/domain.h | 1 +
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
index 8720d126c9..f227309e06 100644
--- a/xen/arch/arm/arm64/domctl.c
+++ b/xen/arch/arm/arm64/domctl.c
@@ -12,6 +12,7 @@
#include <public/domctl.h>
#include <asm/arm64/sve.h>
#include <asm/cpufeature.h>
+#include <xen/guest_access.h>
static long switch_mode(struct domain *d, enum domain_type type)
{
@@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum domain_type type)
return 0;
}
+static long get_address_size(struct domain *d, uint32_t *address_size)
+{
+ long rc = 0;
+ struct vcpu *v;
+ /* Check invalid arguments */
+ if ( d == NULL || address_size == NULL) {
+ rc = -EINVAL;
+ }
+ /* Domain structure type field and actual vcpu mode must be aligned */
+ if(rc == 0) {
+ for_each_vcpu(d, v) {
+ if(vcpu_get_mode(v) != d->arch.type) {
+ rc = -EFAULT;
+ }
+ }
+ }
+
+ if(rc == 0) {
+ if(d->arch.type == DOMAIN_32BIT) {
+ *address_size = 32U;
+ }
+ else if(d->arch.type == DOMAIN_64BIT) {
+ *address_size = 64U;
+ }
+ else {
+ rc = -EFAULT;
+ }
+ }
+ return rc;
+}
+
static long set_address_size(struct domain *d, uint32_t address_size)
{
switch ( address_size )
@@ -54,14 +86,22 @@ static long set_address_size(struct domain *d, uint32_t address_size)
long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
{
+ long rc = 0;
switch ( domctl->cmd )
{
case XEN_DOMCTL_set_address_size:
- return set_address_size(d, domctl->u.address_size.size);
-
+ rc = set_address_size(d, domctl->u.address_size.size);
+ break;
+ case XEN_DOMCTL_get_address_size:
+ rc = get_address_size(d, &domctl->u.address_size.size);
+ if(__copy_to_guest(u_domctl, domctl, 1)) {
+ rc = -EFAULT;
+ }
+ break;
default:
- return -ENOSYS;
+ rc = -ENOSYS;
}
+ return rc;
}
/*
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1a8585d02b..9096dc7411 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -608,6 +608,11 @@ void vcpu_switch_to_aarch64_mode(struct vcpu *v)
v->arch.hcr_el2 |= HCR_RW;
}
+unsigned int vcpu_get_mode(struct vcpu *v)
+{
+ return v->arch.hcr_el2 & HCR_RW ? DOMAIN_64BIT : DOMAIN_32BIT;
+}
+
int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
{
unsigned int max_vcpus;
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
index af3e168374..e64402a67d 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -252,6 +252,7 @@ struct arch_vcpu
void vcpu_show_registers(struct vcpu *v);
void vcpu_switch_to_aarch64_mode(struct vcpu *v);
+unsigned int vcpu_get_mode(struct vcpu *v);
/*
* Due to the restriction of GICv3, the number of vCPUs in AFF0 is
--
2.43.0On Wed Oct 1, 2025 at 10:01 PM CEST, Milan Djokic wrote: > Signed-off-by: Milan Djokic <milan_djokic@epam.com> > > --- > XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86) > It would be useful to have this hypercall supported for arm64, in order to get > current guest addressing mode Why is this helpful? You're racing against the guest transitioning between 32 and 64 bits, so the result is stale by the time you read it. Do you care about the instantanerous bitness of the vCPU or whether you created a 32 or 64 bit guest? > and also to verify that XEN_DOMCTL_set_address_size > performs switch to target addressing mode (instead of relying on its returned error code only). You can't use that in HVM. Even if you could, why would you? What's the ultimate goal? Cheers, Alejandro
On 01/10/2025 9:01 pm, Milan Djokic wrote:
> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>
> ---
> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
> It would be useful to have this hypercall supported for arm64, in order to get
> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
> performs switch to target addressing mode (instead of relying on its returned error code only).
Please don't copy this misfeature of x86 PV guests into ARM.
Letting domains be of variable bitness after domain create leads to a
whole lot of bugs, many security relevant.
32bit vs 64bit should be an input to domain_create(), not something that
is edited after the domain has been constructed.
> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
> index 8720d126c9..f227309e06 100644
> --- a/xen/arch/arm/arm64/domctl.c
> +++ b/xen/arch/arm/arm64/domctl.c
> @@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum domain_type type)
> return 0;
> }
>
> +static long get_address_size(struct domain *d, uint32_t *address_size)
> +{
> + long rc = 0;
> + struct vcpu *v;
> + /* Check invalid arguments */
> + if ( d == NULL || address_size == NULL) {
> + rc = -EINVAL;
> + }
> + /* Domain structure type field and actual vcpu mode must be aligned */
> + if(rc == 0) {
> + for_each_vcpu(d, v) {
> + if(vcpu_get_mode(v) != d->arch.type) {
> + rc = -EFAULT;
> + }
> + }
This is deeply suspicious.
Under what circumstances can the vCPU setting be different from the
domain setting?
~Andrew
On 10/2/25 06:10, Andrew Cooper wrote: > On 01/10/2025 9:01 pm, Milan Djokic wrote: >> Signed-off-by: Milan Djokic <milan_djokic@epam.com> >> >> --- >> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86) >> It would be useful to have this hypercall supported for arm64, in order to get >> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size >> performs switch to target addressing mode (instead of relying on its returned error code only). > > Please don't copy this misfeature of x86 PV guests into ARM. > > Letting domains be of variable bitness after domain create leads to a > whole lot of bugs, many security relevant. > > 32bit vs 64bit should be an input to domain_create(), not something that > is edited after the domain has been constructed. Does this mean that Xen guests cannot support multiarch? -- Sincerely, Demi Marie Obenour (she/her/hers)
Hi Demi, On 02/10/2025 19:27, Demi Marie Obenour wrote: > On 10/2/25 06:10, Andrew Cooper wrote: >> On 01/10/2025 9:01 pm, Milan Djokic wrote: >>> Signed-off-by: Milan Djokic <milan_djokic@epam.com> >>> >>> --- >>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86) >>> It would be useful to have this hypercall supported for arm64, in order to get >>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size >>> performs switch to target addressing mode (instead of relying on its returned error code only). >> >> Please don't copy this misfeature of x86 PV guests into ARM. >> >> Letting domains be of variable bitness after domain create leads to a >> whole lot of bugs, many security relevant. >> >> 32bit vs 64bit should be an input to domain_create(), not something that >> is edited after the domain has been constructed. > > Does this mean that Xen guests cannot support multiarch? I can't speak for x86. But for Arm, the endianess of EL1 (OS) is fixed when the vCPU is booting. You could in theory have a domain with a mix of 64-bit and 32-bit vCPUs. But that's not supported by Xen (all vCPUs should have the same bitness) and also I am not aware of any mainstream OS able to deal with multiple bitness. Most likely, you will need to run two OSes and create your custom OS. Also, I believe XEN_DOMCTL_get_address_size would not be suitable for such setup. Cheers, -- Julien Grall
On 10/3/25 06:14, Julien Grall wrote: > Hi Demi, > > On 02/10/2025 19:27, Demi Marie Obenour wrote: >> On 10/2/25 06:10, Andrew Cooper wrote: >>> On 01/10/2025 9:01 pm, Milan Djokic wrote: >>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com> >>>> >>>> --- >>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86) >>>> It would be useful to have this hypercall supported for arm64, in order to get >>>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size >>>> performs switch to target addressing mode (instead of relying on its returned error code only). >>> >>> Please don't copy this misfeature of x86 PV guests into ARM. >>> >>> Letting domains be of variable bitness after domain create leads to a >>> whole lot of bugs, many security relevant. >>> >>> 32bit vs 64bit should be an input to domain_create(), not something that >>> is edited after the domain has been constructed. >> >> Does this mean that Xen guests cannot support multiarch? > > I can't speak for x86. But for Arm, the endianess of EL1 (OS) is fixed > when the vCPU is booting. You could in theory have a domain with a mix > of 64-bit and 32-bit vCPUs. But that's not supported by Xen (all vCPUs > should have the same bitness) and also I am not aware of any mainstream > OS able to deal with multiple bitness. Most likely, you will need to run > two OSes and create your custom OS. > > Also, I believe XEN_DOMCTL_get_address_size would not be suitable for > such setup. I meant multiarch in userspace. Running a 32-bit kernel makes no sense. If that is something Arm OSs just don't support that's fine too. -- Sincerely, Demi Marie Obenour (she/her/hers)
On Thu Oct 2, 2025 at 8:27 PM CEST, Demi Marie Obenour wrote: > On 10/2/25 06:10, Andrew Cooper wrote: >> On 01/10/2025 9:01 pm, Milan Djokic wrote: >>> Signed-off-by: Milan Djokic <milan_djokic@epam.com> >>> >>> --- >>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86) >>> It would be useful to have this hypercall supported for arm64, in order to get >>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size >>> performs switch to target addressing mode (instead of relying on its returned error code only). >> >> Please don't copy this misfeature of x86 PV guests into ARM. >> >> Letting domains be of variable bitness after domain create leads to a >> whole lot of bugs, many security relevant. >> >> 32bit vs 64bit should be an input to domain_create(), not something that >> is edited after the domain has been constructed. > > Does this mean that Xen guests cannot support multiarch? HVM/PVH x86_64 cannot not be multiarch. All APs start in 16bit and proceed to 32 and 64 bit mode, in that order. It's only PV that has fixed bitness. Cheers, Alejandro
Hello Andrew,
On 10/2/25 12:10, Andrew Cooper wrote:
> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>
>> ---
>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
>> It would be useful to have this hypercall supported for arm64, in order to get
>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
>> performs switch to target addressing mode (instead of relying on its returned error code only).
>
> Please don't copy this misfeature of x86 PV guests into ARM.
>
> Letting domains be of variable bitness after domain create leads to a
> whole lot of bugs, many security relevant.
>
> 32bit vs 64bit should be an input to domain_create(), not something that
> is edited after the domain has been constructed.
>
Yes, the idea behind this patch is not to introduce variable bitness,
just to have the ability to get current addressing mode through
hypercall. In our case, we have used it only in domain creation path
(after domain_create(), to verify that target addressing mode is set).
Of course, whether this hypercall support would be useful in mainline is
open for discussion.
>> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
>> index 8720d126c9..f227309e06 100644
>> --- a/xen/arch/arm/arm64/domctl.c
>> +++ b/xen/arch/arm/arm64/domctl.c
>> @@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum domain_type type)
>> return 0;
>> }
>>
>> +static long get_address_size(struct domain *d, uint32_t *address_size)
>> +{
>> + long rc = 0;
>> + struct vcpu *v;
>> + /* Check invalid arguments */
>> + if ( d == NULL || address_size == NULL) {
>> + rc = -EINVAL;
>> + }
>> + /* Domain structure type field and actual vcpu mode must be aligned */
>> + if(rc == 0) {
>> + for_each_vcpu(d, v) {
>> + if(vcpu_get_mode(v) != d->arch.type) {
>> + rc = -EFAULT;
>> + }
>> + }
>
> This is deeply suspicious.
>
> Under what circumstances can the vCPU setting be different from the
> domain setting?
>
It should never happen, this is more of a sanity check. Alternative
would be to use only one of vCPU or domain settings, checking against
both seemed more complete to me.
> ~Andrew
BR,
Milan
Hi,
On 02/10/2025 12:10, Milan Djokic wrote:
> Hello Andrew,
>
> On 10/2/25 12:10, Andrew Cooper wrote:
>> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>>
>>> ---
>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm
>>> (only for x86)
>>> It would be useful to have this hypercall supported for arm64, in
>>> order to get
>>> current guest addressing mode and also to verify that
>>> XEN_DOMCTL_set_address_size
>>> performs switch to target addressing mode (instead of relying on its
>>> returned error code only).
>>
>> Please don't copy this misfeature of x86 PV guests into ARM.
>>
>> Letting domains be of variable bitness after domain create leads to a
>> whole lot of bugs, many security relevant.
>>
>> 32bit vs 64bit should be an input to domain_create(), not something that
>> is edited after the domain has been constructed.
>>
>
> Yes, the idea behind this patch is not to introduce variable bitness,
> just to have the ability to get current addressing mode through
> hypercall. In our case, we have used it only in domain creation path
> (after domain_create(), to verify that target addressing mode is set).
> Of course, whether this hypercall support would be useful in mainline is
> open for discussion.
We already have a series under review [1] that follow what Andrew is
suggesting. I would rather focus on getting it committed rather than
trying to workaround it.
>
>>> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
>>> index 8720d126c9..f227309e06 100644
>>> --- a/xen/arch/arm/arm64/domctl.c
>>> +++ b/xen/arch/arm/arm64/domctl.c
>>> @@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum
>>> domain_type type)
>>> return 0;
>>> }
>>> +static long get_address_size(struct domain *d, uint32_t *address_size)
>>> +{
>>> + long rc = 0;
>>> + struct vcpu *v;
>>> + /* Check invalid arguments */
>>> + if ( d == NULL || address_size == NULL) {
>>> + rc = -EINVAL;
>>> + }
>>> + /* Domain structure type field and actual vcpu mode must be
>>> aligned */
>>> + if(rc == 0) {
>>> + for_each_vcpu(d, v) {
>>> + if(vcpu_get_mode(v) != d->arch.type) {
>>> + rc = -EFAULT;
>>> + }
>>> + }
>>
>> This is deeply suspicious.
>>
>> Under what circumstances can the vCPU setting be different from the
>> domain setting?
>>
>
> It should never happen, this is more of a sanity check. Alternative
> would be to use only one of vCPU or domain settings, checking against
> both seemed more complete to me.
This would be a logical error in Xen rather than something that could be
triggered by the toolstack. I feel it could mislead people using release
build because the fault is not due to the input provided.
Cheers,
--
Julien Grall
Hi Julien,
On 10/2/25 14:43, Julien Grall wrote:
> Hi,
>
> On 02/10/2025 12:10, Milan Djokic wrote:
>> Hello Andrew,
>>
>> On 10/2/25 12:10, Andrew Cooper wrote:
>>> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>>>
>>>> ---
>>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm
>>>> (only for x86)
>>>> It would be useful to have this hypercall supported for arm64, in
>>>> order to get
>>>> current guest addressing mode and also to verify that
>>>> XEN_DOMCTL_set_address_size
>>>> performs switch to target addressing mode (instead of relying on its
>>>> returned error code only).
>>>
>>> Please don't copy this misfeature of x86 PV guests into ARM.
>>>
>>> Letting domains be of variable bitness after domain create leads to a
>>> whole lot of bugs, many security relevant.
>>>
>>> 32bit vs 64bit should be an input to domain_create(), not something that
>>> is edited after the domain has been constructed.
>>>
>>
>> Yes, the idea behind this patch is not to introduce variable bitness,
>> just to have the ability to get current addressing mode through
>> hypercall. In our case, we have used it only in domain creation path
>> (after domain_create(), to verify that target addressing mode is set).
>> Of course, whether this hypercall support would be useful in mainline is
>> open for discussion.
>
> We already have a series under review [1] that follow what Andrew is
> suggesting. I would rather focus on getting it committed rather than
> trying to workaround it.
>
Thank you for clarification. In that case, I will abandon this patch.
You are referring to path series from Grygorii [1]? This means that
XEN_DOMCTL_set_address_size hypercall will be removed and its function
integrated as part of domain_create() and XEN_DOMCTL_createdomain (for
toolstack) hypercall?
>>
>>>> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
>>>> index 8720d126c9..f227309e06 100644
>>>> --- a/xen/arch/arm/arm64/domctl.c
>>>> +++ b/xen/arch/arm/arm64/domctl.c
>>>> @@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum
>>>> domain_type type)
>>>> return 0;
>>>> }
>>>> +static long get_address_size(struct domain *d, uint32_t *address_size)
>>>> +{
>>>> + long rc = 0;
>>>> + struct vcpu *v;
>>>> + /* Check invalid arguments */
>>>> + if ( d == NULL || address_size == NULL) {
>>>> + rc = -EINVAL;
>>>> + }
>>>> + /* Domain structure type field and actual vcpu mode must be
>>>> aligned */
>>>> + if(rc == 0) {
>>>> + for_each_vcpu(d, v) {
>>>> + if(vcpu_get_mode(v) != d->arch.type) {
>>>> + rc = -EFAULT;
>>>> + }
>>>> + }
>>>
>>> This is deeply suspicious.
>>>
>>> Under what circumstances can the vCPU setting be different from the
>>> domain setting?
>>>
>>
>> It should never happen, this is more of a sanity check. Alternative
>> would be to use only one of vCPU or domain settings, checking against
>> both seemed more complete to me.
>
> This would be a logical error in Xen rather than something that could be
> triggered by the toolstack. I feel it could mislead people using release
> build because the fault is not due to the input provided.
>
> Cheers,
>
[1]
https://patchwork.kernel.org/project/xen-devel/cover/20250911082034.1326377-1-grygorii_strashko@epam.com/
BR,
Milan
© 2016 - 2025 Red Hat, Inc.