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 <[email protected]> > > --- 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. On x86, it doesn't remotely work because of the pointer size mismatch, 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. > 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. > 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, and "the guest kernel can DoS itself" isn't interesting. ~Andrew
