public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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(-)
> 


  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).