linux-kernel - Re: [PATCH] Increase default MLOCK

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:   Wed, 24 Nov 2021 09:48:12 -0400
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     David Hildenbrand <david@...hat.com>
Cc:     Vlastimil Babka <vbabka@...e.cz>, Jens Axboe <axboe@...nel.dk>,
        Andrew Dona-Couch <andrew@...acou.ch>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Drew DeVault <sir@...wn.com>,
        Ammar Faizi <ammarfaizi2@...weeb.org>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        io_uring Mailing List <io-uring@...r.kernel.org>,
        Pavel Begunkov <asml.silence@...il.com>, linux-mm@...ck.org
Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB

On Wed, Nov 24, 2021 at 02:29:38PM +0100, David Hildenbrand wrote:
> On 24.11.21 14:28, Jason Gunthorpe wrote:
> > On Wed, Nov 24, 2021 at 02:25:09PM +0100, David Hildenbrand wrote:
> >> On 24.11.21 14:23, Jason Gunthorpe wrote:
> >>> On Wed, Nov 24, 2021 at 09:57:32AM +0100, David Hildenbrand wrote:
> >>>
> >>>> Unfortunately it will only be a band aid AFAIU. I can rewrite my
> >>>> reproducer fairly easily to pin the whole 2M range first, pin a second
> >>>> time only a single page, and then unpin the 2M range, resulting in the
> >>>> very same way to block THP. (I can block some THP less because I always
> >>>> need the possibility to memlock 2M first, though).
> >>>
> >>> Oh!
> >>>
> >>> The issue is GUP always pins an entire compound, no matter how little
> >>> the user requests.
> >>
> >> That's a different issue. I make sure to split the compound page before
> >> pinning anything :)
> > 
> > ?? Where is that done in GUP?
> 
> It's done in my reproducer manually.

Aren't there many ways for hostile unpriv userspace to cause memory
fragmentation? You are picking on pinning here, but any approach that
forces the kernel to make a kalloc on a THP subpage would do just as
well.

Arguably if we want to point to an issue here it is in MADV_FREE/etc
that is the direct culprit in allowing userspace to break up THPs and
then trigger fragmentation.

If the objective is to prevent DOS of THP then MADV_FREE should
conserve the THP and migrate the subpages to non-THP
memory.

FOLL_LONGTERM is not the issue here.

Jason