linux-kernel - Re: [Xen-devel] [PATCH 1/2] xen/gntdev: replace global limit of mapped pages by limit per call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 19 Jul 2019 06:06:18 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Andrew Cooper <andrew.cooper3@...rix.com>,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Cc:     Stefano Stabellini <sstabellini@...nel.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/gntdev: replace global limit of
 mapped pages by limit per call

On 18.07.19 19:36, Andrew Cooper wrote:
> On 18/07/2019 07:52, Juergen Gross wrote:
>> Today there is a global limit of pages mapped via /dev/xen/gntdev set
>> to 1 million pages per default.
> 
> The Xen default limit even for dom0 is 1024 pages * 16 entries per page,
> which is far lower than this limit.

Actually its 256 entries per page, but this is still lower than the
current limit.

> 
>> There is no reason why that limit is
>> existing, as total number of foreign mappings is limited by the
> 
> s/foreign/grant/ ?

Can do.

> 
>> hypervisor anyway and preferring kernel mappings over userspace ones
>> doesn't make sense.
> 
> Its probably also worth stating that this a root-only device, which
> further brings in to question the user/kernel split.

Yes.

> 
>>
>> Additionally checking of that limit is fragile, as the number of pages
>> to map via one call is specified in a 32-bit unsigned variable which
>> isn't tested to stay within reasonable limits (the only test is the
>> value to be <= zero, which basically excludes only calls without any
>> mapping requested). So trying to map e.g. 0xffff0000 pages while
>> already nearly 1000000 pages are mapped will effectively lower the
>> global number of mapped pages such that a parallel call mapping a
>> reasonable amount of pages can succeed in spite of the global limit
>> being violated.
>>
>> So drop the global limit and introduce per call limit instead.
> 
> Its probably worth talking about this new limit.  What is it trying to
> protect?

Out-of-bounds allocations.


Juergen