[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 29 Jan 2021 09:47:01 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uGsQPYwrt1ewXAnFI6kp+vAPC40PetQEqJ/Y4YRcI4U=; b=AyrJfRS4eHZC1EqcjNNfuIGu7YH0xnQBdU6gh1EtTJAKx/6X1wzmC6Zci5L43EW1+Ntqocg92IWTsQWH1xJYcg2hsUFhiydhGN2dAfWVqLEeFNIzGCpTSfhPiQXgFwQFY2TF/2Mxl7AxI8aUcxDp166QRcl2EGXeYQDnn0SnR55KhrtQbN9FcE1LE/KfMXK6kjxkZTLy4E9P5Zbvegg+zmeHqD5BYOF5p/F3dy0TrhCzXf23k19v3a+AIRoXKxFnwiAXRBnHahAaJ5ix6KXkn8s+5H5H0Y6wrLQnlWHc87Mz3OHidY8wcQzAlesn02c+fGHZ+0Suy50N4dhaVCS4vg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jtvDCOrXmj1vFqfly4geySrNDJF24RGzwxpU8mnGBKgNwH4ZhnGame+0UxUiFCntzirjR5e/1rUmhTwjQEMvM6WnrFx0+NPkCGJaPzcMmEmRDbpzr9ugN4hiRd35qbulqEpeIaHylMNN0PbjbMp4ZPggJ91yIUfTNYpmOq08Vn5laO1jnDVDNCarSzviw/09aRd/qPw3tEiuNJJ2/V9ZuhBS7l/R5UkAAUyLujjoF9ZYxGAGvGkExhOrRGwru0VoqxUvjqH4A4XJU22yayYdi9xspYNvo/l1DSOV38rLi0V/pt4/ruFPSR8y+gaUnPFzE6f38uc/GyMmssQzywo9eQ==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 29 Jan 2021 09:47:18 +0000
  • Ironport-sdr: SycWBVuaDPk79vex/U/e5vbQVcr+8qYMEhtcYkVDGjeLFdOxzFFAjtHbmQwpmpG/Z8CKlFhBBV 4VtkYQRyDnvdhZtrw1UVfjewCUbphLpUGKJAAfJ+i7esKJv4PpMAWXCH03qXU7diWS0rFMYuAB YAFfh2Ilc9BE+LM5iZqu9R3Sek7YDiak/rHHJ049VqT7hwvntDCoxCUpj15D2aEXzjTdthK3CE cQRryoacq20sV7Ks7RZ7OMBNlLIVT+9vDfwFooAe3lBHfPkV8YYE93hUkXoDHWbWvkZBNB1peJ eYM=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

>> 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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.