Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v5] mm: Optional full ASLR for mmap(), mremap(), vdso and stack
Date:   Thu, 3 Dec 2020 09:10:32 -0800
Message-Id: <05D72EA3-4862-4D80-82F5-9369834C3461@amacapital.net>
References: <e8c458fe-073b-2c4d-4d80-3637041c1485@gmail.com>
Cc:     Florian Weimer <fweimer@redhat.com>,
        linux-hardening@vger.kernel.org, akpm@linux-foundation.org,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Jann Horn <jannh@google.com>,
        Kees Cook <keescook@chromium.org>,
        Matthew Wilcox <willy@infradead.org>,
        Mike Rapoport <rppt@kernel.org>,
        Linux API <linux-api@vger.kernel.org>
In-Reply-To: <e8c458fe-073b-2c4d-4d80-3637041c1485@gmail.com>
To:     Topi Miettinen <toiwoton@gmail.com>
Precedence: bulk


> On Dec 3, 2020, at 4:06 AM, Topi Miettinen <toiwoton@gmail.com> wrote:
>=20
> =EF=BB=BFOn 3.12.2020 11.47, Florian Weimer wrote:
>> * Topi Miettinen:
>>> +3   Additionally enable full randomization of memory mappings created
>>> +    with mmap(NULL, ...). With 2, the base of the VMA used for such
>>> +    mappings is random, but the mappings are created in predictable
>>> +    places within the VMA and in sequential order. With 3, new VMAs
>>> +    are created to fully randomize the mappings.
>>> +
>>> +    Also mremap(..., MREMAP_MAYMOVE) will move the mappings even if
>>> +    not necessary and the location of stack and vdso are also
>>> +    randomized.
>>> +
>>> +    On 32 bit systems this may cause problems due to increased VM
>>> +    fragmentation if the address space gets crowded.
>> Isn't this a bit of an understatement?  I think you'll have to restrict
>> this randomization to a subregion of the entire address space, otherwise
>> the reduction in maximum mapping size due to fragmentation will be a
>> problem on 64-bit architectures as well (which generally do not support
>> the full 64 bits for user-space addresses).
>=20
> Restricting randomization would reduce the address space layout randomizat=
ion and make this less useful. There's 48 or 56 bits, which translate to 128=
TB and 64PB of VM for user applications. Is it really possible to build toda=
y (or in near future) a system, which would contain so much RAM that such fr=
agmentation could realistically happen? Perhaps also in a special case where=
 lots of 1GB huge pages are necessary? Maybe in those cases you shouldn't us=
e randomize_va_space=3D3. Or perhaps there could be randomize_va_space=3D3 w=
hich does something, and randomize_va_space=3D4 for those who want maximum r=
andomization.

If you want a 4GB allocation to succeed, you can only divide the address spa=
ce into 32k fragments.  Or, a little more precisely, if you want a randomly s=
elected 4GB region to be empty, any other allocation has a 1/32k chance of b=
eing in the way.  (Rough numbers =E2=80=94 I=E2=80=99m ignoring effects of t=
he beginning and end of the address space, and I=E2=80=99m ignoring the size=
 of a potential conflicting allocation.). This sounds good, except that a pr=
ogram could easily make a whole bunch of tiny allocations that get merged in=
 current kernels but wouldn=E2=80=99t with your scheme.

So maybe this is okay, but it=E2=80=99s not likely to be a good default.

>=20
>>> +    On all systems, it will reduce performance and increase memory
>>> +    usage due to less efficient use of page tables and inability to
>>> +    merge adjacent VMAs with compatible attributes. In the worst case,
>>> +    additional page table entries of up to 4 pages are created for
>>> +    each mapping, so with small mappings there's considerable penalty.
>> The number 4 is architecture-specific, right?
>=20
> Yes, I only know x86_64. Actually it could have 5 level page tables. I'll f=
ix this in next version.
>=20
> -Topi