From: Topi Miettinen <toiwoton@gmail.com>
To: libc-alpha@sourceware.org
Subject: Re: [RFC PATCH 0/3] Improved ALSR
Date: Mon, 23 Nov 2020 18:06:01 +0200 [thread overview]
Message-ID: <a55194d2-d7e7-0bef-c852-d6d92e40a85b@gmail.com> (raw)
In-Reply-To: <20201004130938.64575-1-toiwoton@gmail.com>
On 4.10.2020 16.09, Topi Miettinen wrote:
> Problem with using sbrk() for allocations is that the location of the
> memory is relatively predicatable since it's always located next to
> data segment. This series makes malloc() and TCB use mmap() instead.
No comments at all? I see several implementation options here:
1. Always use mmap() instead of sbrk(), delete any uses of sbrk()
I have hard time thinking why sbrk() would ever be the preferred choice
over mmap(), especially considering security. There may be some bytes
wasted, so embedded systems could want to save those and also MMU-less
systems can't map pages anywhere, but then those probably won't use glibc.
2. Conditionally use mmap() instead of sbrk()
Something like `#define USE_SBRK`, enabled by `configure` or a header
file. Sub-options:
2.1. Default to sbrk(), use mmap() only for Linux
This is of course safer if some obscure system needs sbrk(). It would be
even safer to limit mmap() only to Linux/x86_64 (which is all I care).
2.2. Default to mmap() but don't enable sbrk() anywhere
This is pretty much like #1 but after breakage is noticed for some
obscure systems, it's easy to `#define USE_SBRK` somewhere.
I've been using a patched glibc for a month without seeing problems. I
enabled audit logging for the brk() system call and installed a global
seccomp filter (in initrd) which returns ENOSYS to catch any uses. So
far I've only noticed that cpp (used by X11 startup in addition to
compiling) calls sbrk() to check memory usage. Perhaps it should use
official malloc statistics interface instead, since malloc() may use
mmap() for other reasons and then sbrk() won't return true data.
It's easy to check that sbrk() has not been used with the command `grep
'\[heap\]' /proc/*/maps` (as root), which should print nothing since
there are no heaps (as in "extended data segment") anymore.
-Topi
> Topi Miettinen (3):
> csu: randomize location of TCB
> malloc: always use mmap() to improve ASLR
> dl-sysdep: disable remaining calls to sbrk()
>
> csu/libc-tls.c | 20 ++++++++++++++------
> elf/dl-sysdep.c | 2 ++
> malloc/arena.c | 5 ++++-
> malloc/malloc.c | 16 +++++++++++++---
> malloc/morecore.c | 2 ++
> sysdeps/unix/sysv/linux/dl-sysdep.c | 2 ++
> sysdeps/unix/sysv/linux/mmap64.c | 19 +++++++++++++++++++
> sysdeps/unix/sysv/linux/mmap_internal.h | 3 +++
> 8 files changed, 59 insertions(+), 10 deletions(-)
>
next prev parent reply other threads:[~2020-11-23 16:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-04 13:09 Topi Miettinen
2020-10-04 13:09 ` [RFC PATCH 1/3] csu: randomize location of TCB Topi Miettinen
2020-11-24 18:44 ` Adhemerval Zanella
2020-10-04 13:09 ` [RFC PATCH 2/3] malloc: always use mmap() to improve ASLR Topi Miettinen
2020-10-04 13:09 ` [RFC PATCH 3/3] dl-sysdep: disable remaining calls to sbrk() Topi Miettinen
2020-11-23 16:06 ` Topi Miettinen [this message]
2020-11-23 16:41 ` [RFC PATCH 0/3] Improved ALSR Szabolcs Nagy
2020-11-23 17:55 ` Topi Miettinen
2020-11-23 21:45 ` Florian Weimer
2020-11-23 22:28 ` Topi Miettinen
2020-11-24 11:24 ` Florian Weimer
2020-11-24 11:59 ` Topi Miettinen
2020-11-24 14:29 ` Adhemerval Zanella
2020-11-30 10:28 ` Florian Weimer
2020-11-30 11:39 ` Topi Miettinen
2020-11-23 16:44 ` Florian Weimer
2020-11-23 18:16 ` Topi Miettinen
2020-11-24 9:47 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a55194d2-d7e7-0bef-c852-d6d92e40a85b@gmail.com \
--to=toiwoton@gmail.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).