Re: [PATCH] xen/memory: Reject out-of-range resource 'frame' values

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/01/2021 09:40, Jan Beulich wrote:
> On 29.01.2021 10:32, Andrew Cooper wrote:
>> On 29/01/2021 09:15, Jan Beulich wrote:
>>> On 28.01.2021 17:06, Andrew Cooper wrote:
>>>> --- a/xen/common/memory.c
>>>> +++ b/xen/common/memory.c
>>>> @@ -1054,7 +1054,7 @@ static long xatp_permission_check(struct domain *d, 
>>>> unsigned int space)
>>>>  }
>>>>  
>>>>  static int acquire_grant_table(struct domain *d, unsigned int id,
>>>> -                               unsigned long frame,
>>>> +                               unsigned int frame,
>>>>                                 unsigned int nr_frames,
>>>>                                 xen_pfn_t mfn_list[])
>>>>  {
>>> Doesn't this want carrying forward into
>>> gnttab_get_{shared,status}_frame() as well? Of course further
>>> cleanup here can also be done at a later point, but it leaves
>>> things in a somewhat inconsistent state. I'd like to leave it
>>> up to you to commit with Paul's R-b as is, or extend the
>>> adjustments and then also add mine.
>> In the series, those functions are deleted by the next patch.
> In your submission you talk about a v8 series, which I took to
> mean the vmtrace one. I understand here you refer to the other
> series, presently at v3?

The two combined is v8 because of the dependencies (and that's what I'll
post all together), but yes - I did mean the thing presently at v3 as
posted.

>
>> What's the likelihood that you'll choose to backport this?
> Didn't consider this aspect yet. I think I wouldn't have picked
> it without anyone asking for it to be backported.
>
>>   I can extend it if needs be.
> Well, if that deletion of code gets committed in time, then of
> course there's no real need to fiddle with it here.

This specific patch fixes a real bug on arm32 which will cause unsigned
long + unsigned int to truncate together and permit certain values.

If you want to backport it, I should extend the change all the way down
the call tree.

The rest of the cleanup really depends on the libxenforeignmem change,
and ioctl fixes in the kernel, and probably aren't suitable for backport.

~Andrew