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] [thread-next>] [day] [month] [year] [list]

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

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.

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

s/foreign/grant/ ?

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

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

~Andrew