linux-kernel - Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

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: <20170710165214.GC21543@1wt.eu>
Date:   Mon, 10 Jul 2017 18:52:14 +0200
From:   Willy Tarreau <w@....eu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Michal Hocko <mhocko@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Ben Hutchings <ben@...adent.org.uk>,
        Hugh Dickins <hughd@...gle.com>,
        Oleg Nesterov <oleg@...hat.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...hat.com>,
        Larry Woodman <lwoodman@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Tony Luck <tony.luck@...el.com>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Helge Diller <deller@....de>,
        James Hogan <james.hogan@...tec.com>,
        Laura Abbott <labbott@...hat.com>, Greg KH <greg@...ah.com>,
        "security@...nel.org" <security@...nel.org>,
        Qualys Security Advisory <qsa@...lys.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ximin Luo <infinity0@...ian.org>
Subject: Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Mon, Jul 10, 2017 at 09:18:09AM -0700, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 9:12 AM, Kees Cook <keescook@...omium.org> wrote:
> >
> > Sounds good to me, but won't large-memory users in 32-bit get annoyed?
> 
> We'll see.
> 
> I suspect that all large-memory users have long since upgraded to
> x86-64 (rule of thumb: if you are upgrading kernels today, you
> probably upgraded hardware ten years ago), and that this may be a
> non-issue today.

I tend to agree. We've been using 32-bit machines with "a lot" (=2GB)
of RAM and haproxy using something like 1.3GB in the past, and it
started to become a bit complex due to ASLR puching large holes between
each and every shared object, forcing us to stop setting strict
overcommit limits for example. We've abandonned them after kernel 3.10,
when the new models had been migrated to 64 bits a few years ago already
and I think anyone doing anything serious with memory doesn't use 32-bit
at all.

Well I know of one exception :-)  My netbook has 3 GB and is 32-bit,
running on 4.9 :

willy@...pc:~$ uname -a
Linux eeepc 4.9.36-eeepc #1 SMP Mon Jul 10 07:33:29 CEST 2017 i686 Intel(R) Atom(TM) CPU N2800   @ 1.86GHz GenuineIntel GNU/Linux
willy@...pc:~$ free
             total       used       free     shared    buffers     cached
Mem:       3097840     649816    2448024          0      52476     507216
-/+ buffers/cache:      90124    3007716
Swap:      1025440          0    1025440

It only runs end-user stuff (firefox) so it cannot be considered anything
serious.

Willy