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 for Android: free password hash cracker in your pocket

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

Message-ID: <b84bc345-d4ea-96de-0076-12ff245c5e29@redhat.com>
Date:   Mon, 22 Nov 2021 18:11:28 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Drew DeVault <sir@...wn.com>
Cc:     Ammar Faizi <ammarfaizi2@...weeb.org>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        io_uring Mailing List <io-uring@...r.kernel.org>,
        Jens Axboe <axboe@...nel.dk>,
        Pavel Begunkov <asml.silence@...il.com>, linux-mm@...ck.org
Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB

On 16.11.21 22:37, Andrew Morton wrote:
> On Tue, 16 Nov 2021 20:48:48 +0100 "Drew DeVault" <sir@...wn.com> wrote:
> 
>> On Tue Nov 16, 2021 at 8:47 PM CET, Andrew Morton wrote:
>>> Well, why change the default? Surely anyone who cares is altering it
>>> at runtime anyway. And if they are not, we should encourage them to do
>>> so?
>>
>> I addressed this question in the original patch's commit message.
> 
> Kinda.
> 
> We're never going to get this right, are we?  The only person who can
> decide on a system's appropriate setting is the operator of that
> system.  Haphazardly increasing the limit every few years mainly
> reduces incentive for people to get this right.
> 
> And people who test their software on 5.17 kernels will later find that
> it doesn't work on 5.16 and earlier, so they still need to tell their
> users to configure their systems appropriately.  Until 5.16 is
> obsolete, by which time we're looking at increasing the default again.
> 
> I don't see how this change gets us closer to the desired state:
> getting distros and their users to configure their systems
> appropriately.
> 

My 2 cents: while we should actually try to avoid new FOLL_LONGTERM
users where possible, we introduce more (IOURING_REGISTER_BUFFERS) to be
consumed by ordinary, unprivileged users. These new features, *when
used* require us to raise the MLOCK_LIMIT. Secretmem is similar, but for
now it rather "replaces" old mlock usage and IIRC has similarly small
memory demands; that might change in the future, though.

Why is FOLL_LONGTERM bad? Not only does it prevent swapping like mlock
does, the pages are also unmovable in memory, such that they cannot be
moved around, for example, for memory compaction.

Well, I'm not too mad about IOURING_REGISTER_BUFFERS, it actually helped
me to write a simple reproducer for the COW issues we have in upstream
mm, and can be quite beneficial in some setups. Still, I think it should
be used with care depending on the actual environment.

So, just because a new feature is around that could be used, does it
mean that we should adjust our kernel default? I'd say in this case,
rather not. Distributions, or much better, the responsible admin, should
make such decisions, knowing the environment and the effect this could have.

(I know that we can similarly trigger allocation of a lot of unmovable
memory using other means by malicious user space; but that is rather
something to limit or handle in the future IMHO)

-- 
Thanks,

David / dhildenb