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]
Message-ID: <20220615155659.GA7684@nvidia.com>
Date:   Wed, 15 Jun 2022 12:56:59 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     Alex Williamson <alex.williamson@...hat.com>,
        akpm@...ux-foundation.org, minchan@...nel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, paulmck@...nel.org,
        jhubbard@...dia.com, joaodias@...gle.com
Subject: Re: [PATCH] mm: Re-allow pinning of zero pfns

On Sat, Jun 11, 2022 at 08:29:47PM +0200, David Hildenbrand wrote:
> On 11.06.22 00:35, Alex Williamson wrote:
> > The commit referenced below subtly and inadvertently changed the logic
> > to disallow pinning of zero pfns.  This breaks device assignment with
> > vfio and potentially various other users of gup.  Exclude the zero page
> > test from the negation.
> 
> I wonder which setups can reliably work with a long-term pin on a shared
> zeropage. In a MAP_PRIVATE mapping, any write access via the page tables
> will end up replacing the shared zeropage with an anonymous page.
> Something similar should apply in MAP_SHARED mappings, when lazily
> allocating disk blocks.
> 
> In the future, we might trigger unsharing when taking a R/O pin for the
> shared zeropage, just like we do as of now upstream for shared anonymous
> pages (!PageAnonExclusive). And something similar could then be done
> when finding a !anon page in a MAP_SHARED mapping.

I'm also confused how qemu is hitting this and it isn't already a bug?

It is arising because vfio doesn't use FOLL_FORCE|FOLL_WRITE to move
away the zero page in most cases.

And why does Yishai say it causes an infinite loop in the kernel?

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ