Re: [RFC 02/19] xen: guestcopy: Provide an helper to copy string from guest

[Julien Grall <julien.grall@linaro.org>]

On 17/06/14 10:17, Jan Beulich wrote:
>>>> On 17.06.14 at 11:09, <julien.grall@linaro.org> wrote:
>> On 17/06/14 09:01, Jan Beulich wrote:
>>>>>> On 16.06.14 at 18:17, <julien.grall@linaro.org> wrote:
>>>> +
>>>> +    /* Add an extra +1 to append \0. We can't assume the guest will
>>>> +     * provide a valid string */
>>>
>>> Now this is the case for flask, but for a generic string copying
>>> routine I don't think this is desirable. It seems especially wrong to
>>> aid the guest with putting a NUL where none was. If you really
>>> want this, I guess you would be better off adding two variants:
>>> One which demands the string to be NUL-terminated (in which
>>> case passing in a size is sort of bogus), and one which takes a
>>> size and inserts a NUL.
>>
>> A malicious guest could pass a big buffer without a NUL-terminated. If
>> we don't limit the size and check the NUL-terminated character the guest
>> could respectively exhaust Xen memory and exploit it.
>>
>> Therefore we can't rely on the guest to provide a valid string. This
>> solution will avoid to check in every caller that the string is
>> correctly terminated.
>
> You seem to imply that by not passing in a size I also meant not
> passing in a maximum size - I didn't say that, though. You absolutely
> have to limit the string length for security reasons, but it's clearly a
> difference whether you silently NUL-terminate the value after the
> maximum number of characters, or return with an error.

I didn't understand in this way your previous mail. Thank you for the 
explanation.

It looks like for my use case it's better to throw an error if we don't 
have enough place. It would help us if one day the path start to be very 
long.

I'm wondering if we can also make this change for flask... Daniel, any 
though?

Regards,

-- 
Julien Grall