Re: [PATCH 12/12] SUPPORT.md: write down restriction of 32-bit tool stacks

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.06.2021 21:45, Andrew Cooper wrote:
> On 25/06/2021 14:24, Jan Beulich wrote:
>> Let's try to avoid giving the impression that 32-bit tool stacks are as
>> capable as 64-bit ones.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -131,6 +131,11 @@ ARM only has one guest type at the momen
>>  
>>  ## Toolstack
>>  
>> +While 32-bit builds of the tool stack are generally supported, restrictions
>> +apply in particular when running on top of a 64-bit hypervisor.
> 
> Actually, this isn't true, and in a way which helps us right now.
> 
> PV32 isn't security supported, and neither ARM nor x86 support dom0
> bitness != Xen bitness.

While I agree this may be one possible way of the recent change of
support status for PV32, I didn't so far think "x86 doesn't support
dom0 bitness != Xen bitness" was stated anywhere. The recent change
was about security support only, yet Dom0 isn't covered by this as
far as its status as a "guest" goes. This view of mine is, I think,
supported by osstest actually spending a fair share of its effort
on testing exactly this.

Also please don't forget that besides a (64,32,32) tuple of (Xen,
Dom0-kernel,Dom0-userspace) there's also the possible (64,64,32)
one.

>  On x86, it doesn't remotely work because of the
> pointer size mismatch,

Are you saying this for (64,32,32) or (64,64,32)? In any event I
have to admit that I don't see where pointer size (and it not
matching) would make this in principle impossible. That's what
both Xen and kernel have compat layers for.

> and while this was bodged in a horrifying way in
> the ARM ABI, I doubt anyone is in a hurry to turn that into a supported
> configuration.
> 
> That said, it is my intent with the ABIv2 changes for a 32bit toolstack,
> under 64bit guest kernel, under 64bit or 128bit Xen (yes - RISCV-128 is
> already a thing being discussed) to function.

I'm curious what your plans are there. Afaict accommodating 128-
bit in the ABI right away would be a good idea, by end up bloating
structures unnecessarily. But perhaps you have some clever ideas
there ...

>>   For example,
>> +very large guests aren't supported in this case.
> 
> The wording here wants to be careful, because under certain readings,
> you've just dropped security support for 32bit toolstacks.
> 
> What we actually mean is "a toolstack with bitness < Xen is not expected
> to be able to manage very large domains correctly, and don't pester us
> with bugs when it doesn't work because we won't fix them".
> 
> Whereas we will fix security issues which only happen to manifest in
> 32bit builds of the toolstack.

I've replaced "supported" by "expected to be manageable". If this
still doesn't fit, then please provide sufficient detail for me
to derive what wording would suit you.

>>   This includes guests giving
>> +the appearance of being large, by altering their own memory layouts.
> 
> I'd drop sentence.  Its an internal detail of a corner case which we're
> expecting to remove in the future,

But this is the main reason for us having notice the lack of clear
statement here. Plus within the current ABI I don't see us having
any means to remove all the truncation issues. We shall be glad if
we get a 64-bit tool stack to correctly deal with such guests
(performance aside).

> and "the guest kernel can DoS itself" isn't interesting.

Of course there's no intention to state anything about this aspect.

Jan