Re: [PATCH v3 02/10] xen/version: Introduce non-truncating deterministically-signed XENVER_* subops

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/08/2023 8:07 pm, Stefano Stabellini wrote:
> On Wed, 16 Aug 2023, Andrew Cooper wrote:
>> On 16/08/2023 1:19 am, Stefano Stabellini wrote:
>>> On Tue, 15 Aug 2023, Andrew Cooper wrote:
>>>> @@ -498,6 +499,59 @@ static int __init cf_check param_init(void)
>>>>
>>>> +    sz = strlen(str);
>>>> +
>>>> +    if ( sz > KB(64) ) /* Arbitrary limit.  Avoid long-running 
>>>> operations. */
>>>> +        return -E2BIG;
>>> Realistically do we want this buffer to cross page boundaries?
>> A 1-byte answer can cross a page boundary, even if the hypercall
>> argument is correctly aligned (and even that is unspecified in the Xen ABI).
>>
>> But importantly, this series is also prep work to fixing the cmdline
>> limit.  1k is already causing problems, and 64k is a whole lot less bad
>> than 4k when we enter such corner cases.
> OK. It is just that 64K seems *a lot* in this context. But if you have
> reasons to believe that 64K is a good number for this check then OK.

Remember that this is all Xen cross-checking (or reporting to the user)
the length of Xen-owned data.

If the system was only booted only 10 bytes of cmdline, this will only
be 10.

If OTOH there really was 5k of data, handing E2BIG to the user when they
ask for it is slightly rude but is infinitely better than just
truncating it and returning success.

64k is just the upper bounds sanity check for "get a developer to look
at what's going on because this probably isn't what you thought it
was".  Eventually when someone does find a legitimate use for a cmdline
longer than 64k, it will need upping, someone (else) can figure out the
long-running-ness of this scenario.

~Andrew