linux-kernel - Re: [PATCH] mm: optionally disable brk()

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: <7d7b1ac5-d6a7-5e43-8fb8-12b844d7f501@gmail.com>
Date:   Mon, 5 Oct 2020 11:11:35 +0300
From:   Topi Miettinen <toiwoton@...il.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     David Hildenbrand <david@...hat.com>, akpm@...ux-foundation.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: optionally disable brk()

On 5.10.2020 9.12, Michal Hocko wrote:
> On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
>> On 2.10.2020 20.52, David Hildenbrand wrote:
>>> On 02.10.20 19:19, Topi Miettinen wrote:
>>>> The brk() system call allows to change data segment size (heap). This
>>>> is mainly used by glibc for memory allocation, but it can use mmap()
>>>> and that results in more randomized memory mappings since the heap is
>>>> always located at fixed offset to program while mmap()ed memory is
>>>> randomized.
>>>
>>> Want to take more Unix out of Linux?
>>>
>>> Honestly, why care about disabling? User space can happily use mmap() if
>>> it prefers.
>>
>> brk() interface doesn't seem to be used much and glibc is happy to switch to
>> mmap() if brk() fails, so why not allow disabling it optionally? If you
>> don't care to disable, don't do it and this is even the default.
> 
> I do not think we want to have config per syscall, do we? There are many
> other syscalls which are rarely used. Your changelog is actually missing
> the most important part. Why do we care so much to increase the config
> space and make the kerneel even more tricky for users to configure?

Maybe, I didn't know this was an important priority since there are 
other similar config options. Can you suggest some other config option 
which could trigger this? This option is already buried under CONFIG_EXPERT.

> How
> do I know that something won't break? brk() is one of those syscalls
> that has been here for ever and a lot of userspace might depend on it.

1. brk() is used by glibc for malloc() as the primary choice, secondary 
to mmap(NULL, ...). But malloc() switches to using only mmap() as soon 
as brk() fails the first time, without breakage.

2. brk() also used for initializing glibc's internal thread structures. 
The only program I saw having problems was ldconfig which indeed 
segfaults due to an unsafe assumption that sbrk() will never fail. This 
is easily fixable by switching to an internal version of mmap().

3. The dynamic loader uses brk() but this is only done to help malloc() 
and nothing breaks there if brk() returns ENOSYS.

I've sent to glibc list RFC patches which switch to mmap() completely. 
This improves the randomization for malloc()ated memory and the location 
of the thread structures.

> I haven't checked but the code size is very unlikely to be shrunk much
> as this is mostly a tiny wrapper around mmap code. We are not going to
> get rid of any complexity.
> 
> So what is the point?

The point is not to shrink the kernel (it will shrink by one small 
function) or get rid of complexity. The point is to disable an inferior 
interface. Memory returned by mmap() is at a random location but with 
brk() it is located near the data segment, so the address is more easily 
predictable.

I think hardened, security oriented systems should disable brk() 
completely because it will increase the randomization of the process 
address space (ASLR). This wouldn't be a good option to enable for 
systems where maximum compatibility with legacy software is more 
important than any hardening.

-Topi