Message ID | 20201128115945.42732-1-toiwoton@gmail.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C2FCB3858023; Sat, 28 Nov 2020 11:59:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C2FCB3858023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1606564795; bh=T2RPwkmqr24F0l5wxB70uZpRksvuVv20XhGvUjY0sFo=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=dg/3FzxUCFGlY6HCfB/BlJqQUcZNPT1xBGlYuHEQjtFzPuOHM4QxAVf9VeLDfzWNQ BNCicRA8+kF7CZQgR09WSfeKTOJum2QuUKGaMdou1OZ5bkoMUj5Mqz1+UspODay8Gk EHvv+UNzu4AcgkQ6SHF1qFeK9qWqDBOLKZ6B7SX0= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by sourceware.org (Postfix) with ESMTPS id 4FC473858C27 for <libc-alpha@sourceware.org>; Sat, 28 Nov 2020 11:59:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4FC473858C27 Received: by mail-lj1-x244.google.com with SMTP id b17so8970291ljf.12 for <libc-alpha@sourceware.org>; Sat, 28 Nov 2020 03:59:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=T2RPwkmqr24F0l5wxB70uZpRksvuVv20XhGvUjY0sFo=; b=KQuLWPnIysWb9LfMM0y6wolBRDZ7BzdbC5D6eXO24ma5ovE3SwZhjbYwIkfCXzhvNE W/bCX5M+zIT9/9sVVkuO2VhcpElY/cWzXpEpK584An9LogttQc2bkur3Qdz3Ng64QhVc tpGJD4APUzrs47Q9OfNZUvzMFXJHv7UAOGZFPgobXGMfjjfy6T4bl1nK+phrOZTLIufA OCZCaaEoXOZNrOdfS6wVDT36wGLmE5Xny3+Tyy3j7oi/Wq2+D8gF7+gD9rIiu9fKDzEV x/PGcpkb9WjnyVj4wbIFgug+VhsxM4neUcSOC6XvaTMcroOtotl2Yx+Ot03G4iN/aAVi 2NVw== X-Gm-Message-State: AOAM530ITLupLdHCXtJyopj156nPGuZtkD1h8C+s2ZJtgY9zpeLlp53q b18h/rlFQLJw+TBnSjIxr9Mv/LwLMllDwQ== X-Google-Smtp-Source: ABdhPJziTmTSmeJt/2aTZR5fpkBNHsLZKE/iULoUZAdJUBTLneRQHNrSDx8OU+vZ0VEcosg5EqgIlQ== X-Received: by 2002:a2e:6e14:: with SMTP id j20mr5485061ljc.372.1606564790761; Sat, 28 Nov 2020 03:59:50 -0800 (PST) Received: from localhost.localdomain (88-114-211-119.elisa-laajakaista.fi. [88.114.211.119]) by smtp.gmail.com with ESMTPSA id w28sm1055145lfk.8.2020.11.28.03.59.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Nov 2020 03:59:50 -0800 (PST) To: libc-alpha@sourceware.org Subject: [PATCH v2 0/4] Improved ASLR Date: Sat, 28 Nov 2020 13:59:41 +0200 Message-Id: <20201128115945.42732-1-toiwoton@gmail.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Topi Miettinen via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Topi Miettinen <toiwoton@gmail.com> Cc: Topi Miettinen <toiwoton@gmail.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series | Improved ASLR | |
Message
Topi Miettinen
Nov. 28, 2020, 11:59 a.m. UTC
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 the tunables system, malloc() and TCB use mmap() instead, except when instructed by tunable glibc.malloc.use_sbrk. In this version, mmap() is also used for temporary storage for tunables environment variable. Since the tunable to select using sbrk() is unavailable at that point of time, mmap() is always used. mmap() and mmap_noerrno() (other functions use this suffix) have been refactored (Adhemerval Zanella), there's also a version for Hurd. Topi Miettinen (4): csu: randomize location of TCB malloc: use mmap() to improve ASLR dl-sysdep: disable remaining calls to sbrk() tunables: use mmap() instead of sbrk() csu/libc-tls.c | 40 ++++++++++++++++---- elf/dl-sysdep.c | 11 +++++- elf/dl-tunables.c | 9 +++-- elf/dl-tunables.list | 7 ++++ include/sys/mman.h | 5 +++ malloc/arena.c | 11 +++++- malloc/morecore.c | 10 +++++ manual/tunables.texi | 5 +++ sysdeps/mach/hurd/dl-sysdep.c | 18 +++++++-- sysdeps/unix/sysv/linux/dl-sysdep.c | 10 +++++ sysdeps/unix/sysv/linux/mmap.c | 30 ++++++++++++--- sysdeps/unix/sysv/linux/mmap64.c | 23 ++++++++--- sysdeps/unix/sysv/linux/mmap_internal.h | 2 +- sysdeps/unix/sysv/linux/s390/mmap_internal.h | 2 +- 14 files changed, 154 insertions(+), 29 deletions(-) base-commit: aa69f19a937b679816ef10e8620ea1141bb1734b
Comments
On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha 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 the tunables system, malloc() and TCB > use mmap() instead, except when instructed by tunable > glibc.malloc.use_sbrk. The above description is contrary to present reality on Linux. With kernel.randomize_va_space=2 (default), the brk area starts at a randomize gap above end of data/bss. This is *stronger* ASLR than mmap, which aside from the initial gap, generally appears just below the previous map and thereby at a predictable offset from an anchor in a shared library. Rich > In this version, mmap() is also used for temporary storage for > tunables environment variable. Since the tunable to select using > sbrk() is unavailable at that point of time, mmap() is always > used. mmap() and mmap_noerrno() (other functions use this suffix) have > been refactored (Adhemerval Zanella), there's also a version for Hurd. > > Topi Miettinen (4): > csu: randomize location of TCB > malloc: use mmap() to improve ASLR > dl-sysdep: disable remaining calls to sbrk() > tunables: use mmap() instead of sbrk() > > csu/libc-tls.c | 40 ++++++++++++++++---- > elf/dl-sysdep.c | 11 +++++- > elf/dl-tunables.c | 9 +++-- > elf/dl-tunables.list | 7 ++++ > include/sys/mman.h | 5 +++ > malloc/arena.c | 11 +++++- > malloc/morecore.c | 10 +++++ > manual/tunables.texi | 5 +++ > sysdeps/mach/hurd/dl-sysdep.c | 18 +++++++-- > sysdeps/unix/sysv/linux/dl-sysdep.c | 10 +++++ > sysdeps/unix/sysv/linux/mmap.c | 30 ++++++++++++--- > sysdeps/unix/sysv/linux/mmap64.c | 23 ++++++++--- > sysdeps/unix/sysv/linux/mmap_internal.h | 2 +- > sysdeps/unix/sysv/linux/s390/mmap_internal.h | 2 +- > 14 files changed, 154 insertions(+), 29 deletions(-) > > > base-commit: aa69f19a937b679816ef10e8620ea1141bb1734b > -- > 2.29.2
On 3.12.2020 1.09, Rich Felker wrote: > On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha 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 the tunables system, malloc() and TCB >> use mmap() instead, except when instructed by tunable >> glibc.malloc.use_sbrk. > > The above description is contrary to present reality on Linux. With > kernel.randomize_va_space=2 (default), the brk area starts at a > randomize gap above end of data/bss. This is *stronger* ASLR than > mmap, which aside from the initial gap, generally appears just below > the previous map and thereby at a predictable offset from an anchor in > a shared library. Thanks for the review. I'd note that the randomization for brk is only 12 bits, so it's still relatively predictable. With randomize_va_space=3, the randomization provided by mmap() will be much better, the maximum allowed by the kernel design. The best in all cases would be if randomize_va_space=3 could be detected by libc and then it would change the default choice between brk() and mmap() automatically, or libc could generate a random address by itself and use mmap(random_addr,, MAP_FIXED_NOREPLACE) instead of brk(). For example, kernel could use aux vectors to pass the information. -Topi > > Rich > > >> In this version, mmap() is also used for temporary storage for >> tunables environment variable. Since the tunable to select using >> sbrk() is unavailable at that point of time, mmap() is always >> used. mmap() and mmap_noerrno() (other functions use this suffix) have >> been refactored (Adhemerval Zanella), there's also a version for Hurd. >> >> Topi Miettinen (4): >> csu: randomize location of TCB >> malloc: use mmap() to improve ASLR >> dl-sysdep: disable remaining calls to sbrk() >> tunables: use mmap() instead of sbrk() >> >> csu/libc-tls.c | 40 ++++++++++++++++---- >> elf/dl-sysdep.c | 11 +++++- >> elf/dl-tunables.c | 9 +++-- >> elf/dl-tunables.list | 7 ++++ >> include/sys/mman.h | 5 +++ >> malloc/arena.c | 11 +++++- >> malloc/morecore.c | 10 +++++ >> manual/tunables.texi | 5 +++ >> sysdeps/mach/hurd/dl-sysdep.c | 18 +++++++-- >> sysdeps/unix/sysv/linux/dl-sysdep.c | 10 +++++ >> sysdeps/unix/sysv/linux/mmap.c | 30 ++++++++++++--- >> sysdeps/unix/sysv/linux/mmap64.c | 23 ++++++++--- >> sysdeps/unix/sysv/linux/mmap_internal.h | 2 +- >> sysdeps/unix/sysv/linux/s390/mmap_internal.h | 2 +- >> 14 files changed, 154 insertions(+), 29 deletions(-) >> >> >> base-commit: aa69f19a937b679816ef10e8620ea1141bb1734b >> -- >> 2.29.2
On Thu, Dec 03, 2020 at 10:43:29AM +0200, Topi Miettinen wrote: > On 3.12.2020 1.09, Rich Felker wrote: > >On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha 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 the tunables system, malloc() and TCB > >>use mmap() instead, except when instructed by tunable > >>glibc.malloc.use_sbrk. > > > >The above description is contrary to present reality on Linux. With > >kernel.randomize_va_space=2 (default), the brk area starts at a > >randomize gap above end of data/bss. This is *stronger* ASLR than > >mmap, which aside from the initial gap, generally appears just below > >the previous map and thereby at a predictable offset from an anchor in > >a shared library. > > Thanks for the review. I'd note that the randomization for brk is > only 12 bits, so it's still relatively predictable. With > randomize_va_space=3, the randomization provided by mmap() will be > much better, the maximum allowed by the kernel design. The best in > all cases would be if randomize_va_space=3 could be detected by libc > and then it would change the default choice between brk() and mmap() > automatically, or libc could generate a random address by itself and > use mmap(random_addr,, MAP_FIXED_NOREPLACE) instead of brk(). For > example, kernel could use aux vectors to pass the information. Why isn't the proposed randomize_va_space=3 kernel patch just using a completely random base for brk region (and reserving at least a few GB for it to grow into)? Then all existing programs would get the benefit. Rich
On 3.12.2020 17.26, Rich Felker wrote: > On Thu, Dec 03, 2020 at 10:43:29AM +0200, Topi Miettinen wrote: >> On 3.12.2020 1.09, Rich Felker wrote: >>> On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha 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 the tunables system, malloc() and TCB >>>> use mmap() instead, except when instructed by tunable >>>> glibc.malloc.use_sbrk. >>> >>> The above description is contrary to present reality on Linux. With >>> kernel.randomize_va_space=2 (default), the brk area starts at a >>> randomize gap above end of data/bss. This is *stronger* ASLR than >>> mmap, which aside from the initial gap, generally appears just below >>> the previous map and thereby at a predictable offset from an anchor in >>> a shared library. >> >> Thanks for the review. I'd note that the randomization for brk is >> only 12 bits, so it's still relatively predictable. With >> randomize_va_space=3, the randomization provided by mmap() will be >> much better, the maximum allowed by the kernel design. The best in >> all cases would be if randomize_va_space=3 could be detected by libc >> and then it would change the default choice between brk() and mmap() >> automatically, or libc could generate a random address by itself and >> use mmap(random_addr,, MAP_FIXED_NOREPLACE) instead of brk(). For >> example, kernel could use aux vectors to pass the information. > > Why isn't the proposed randomize_va_space=3 kernel patch just > using a completely random base for brk region (and reserving at least > a few GB for it to grow into)? Then all existing programs would get > the benefit. Great idea! I'll try to add that to the patch set. -Topi
On Thu, Dec 03, 2020 at 06:05:56PM +0200, Topi Miettinen wrote: > On 3.12.2020 17.26, Rich Felker wrote: > >On Thu, Dec 03, 2020 at 10:43:29AM +0200, Topi Miettinen wrote: > >>On 3.12.2020 1.09, Rich Felker wrote: > >>>On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha 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 the tunables system, malloc() and TCB > >>>>use mmap() instead, except when instructed by tunable > >>>>glibc.malloc.use_sbrk. > >>> > >>>The above description is contrary to present reality on Linux. With > >>>kernel.randomize_va_space=2 (default), the brk area starts at a > >>>randomize gap above end of data/bss. This is *stronger* ASLR than > >>>mmap, which aside from the initial gap, generally appears just below > >>>the previous map and thereby at a predictable offset from an anchor in > >>>a shared library. > >> > >>Thanks for the review. I'd note that the randomization for brk is > >>only 12 bits, so it's still relatively predictable. With > >>randomize_va_space=3, the randomization provided by mmap() will be > >>much better, the maximum allowed by the kernel design. The best in > >>all cases would be if randomize_va_space=3 could be detected by libc > >>and then it would change the default choice between brk() and mmap() > >>automatically, or libc could generate a random address by itself and > >>use mmap(random_addr,, MAP_FIXED_NOREPLACE) instead of brk(). For > >>example, kernel could use aux vectors to pass the information. > > > >Why isn't the proposed randomize_va_space=3 kernel patch just > >using a completely random base for brk region (and reserving at least > >a few GB for it to grow into)? Then all existing programs would get > >the benefit. > > Great idea! I'll try to add that to the patch set. Great! FYI we also use brk in musl libc's mallocng as a source of memory for metadata areas that are expected not the be at predictable offset from any module's text or data segment or from heap allocations (which all come from mmap), so increased randomization for its location will help a lot. As a related aside, you probably need to recommend increasing vm.max_map_count with kernel.randomize_va_space==3. Otherwise it becomes pretty easy to hit the default VMA limit of 64k. Rich
On 03/12/2020 13:05, Topi Miettinen via Libc-alpha wrote: > On 3.12.2020 17.26, Rich Felker wrote: >> On Thu, Dec 03, 2020 at 10:43:29AM +0200, Topi Miettinen wrote: >>> On 3.12.2020 1.09, Rich Felker wrote: >>>> On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha 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 the tunables system, malloc() and TCB >>>>> use mmap() instead, except when instructed by tunable >>>>> glibc.malloc.use_sbrk. >>>> >>>> The above description is contrary to present reality on Linux. With >>>> kernel.randomize_va_space=2 (default), the brk area starts at a >>>> randomize gap above end of data/bss. This is *stronger* ASLR than >>>> mmap, which aside from the initial gap, generally appears just below >>>> the previous map and thereby at a predictable offset from an anchor in >>>> a shared library. >>> >>> Thanks for the review. I'd note that the randomization for brk is >>> only 12 bits, so it's still relatively predictable. With >>> randomize_va_space=3, the randomization provided by mmap() will be >>> much better, the maximum allowed by the kernel design. The best in >>> all cases would be if randomize_va_space=3 could be detected by libc >>> and then it would change the default choice between brk() and mmap() >>> automatically, or libc could generate a random address by itself and >>> use mmap(random_addr,, MAP_FIXED_NOREPLACE) instead of brk(). For >>> example, kernel could use aux vectors to pass the information. >> >> Why isn't the proposed randomize_va_space=3 kernel patch just >> using a completely random base for brk region (and reserving at least >> a few GB for it to grow into)? Then all existing programs would get >> the benefit. > > Great idea! I'll try to add that to the patch set. Which the sbrk entropy increase, will use mmap on TCB allocation add any security gain?
On 04/12/2020 07:03, Topi Miettinen wrote: > On 3.12.2020 22.33, Adhemerval Zanella wrote: >> >> >> On 03/12/2020 13:05, Topi Miettinen via Libc-alpha wrote: >>> On 3.12.2020 17.26, Rich Felker wrote: >>>> On Thu, Dec 03, 2020 at 10:43:29AM +0200, Topi Miettinen wrote: >>>>> On 3.12.2020 1.09, Rich Felker wrote: >>>>>> On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha 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 the tunables system, malloc() and TCB >>>>>>> use mmap() instead, except when instructed by tunable >>>>>>> glibc.malloc.use_sbrk. >>>>>> >>>>>> The above description is contrary to present reality on Linux. With >>>>>> kernel.randomize_va_space=2 (default), the brk area starts at a >>>>>> randomize gap above end of data/bss. This is *stronger* ASLR than >>>>>> mmap, which aside from the initial gap, generally appears just below >>>>>> the previous map and thereby at a predictable offset from an anchor in >>>>>> a shared library. >>>>> >>>>> Thanks for the review. I'd note that the randomization for brk is >>>>> only 12 bits, so it's still relatively predictable. With >>>>> randomize_va_space=3, the randomization provided by mmap() will be >>>>> much better, the maximum allowed by the kernel design. The best in >>>>> all cases would be if randomize_va_space=3 could be detected by libc >>>>> and then it would change the default choice between brk() and mmap() >>>>> automatically, or libc could generate a random address by itself and >>>>> use mmap(random_addr,, MAP_FIXED_NOREPLACE) instead of brk(). For >>>>> example, kernel could use aux vectors to pass the information. >>>> >>>> Why isn't the proposed randomize_va_space=3 kernel patch just >>>> using a completely random base for brk region (and reserving at least >>>> a few GB for it to grow into)? Then all existing programs would get >>>> the benefit. >>> >>> Great idea! I'll try to add that to the patch set. >> >> Which the sbrk entropy increase, will mmap use on TCB allocation add >> any security gain? > > I think the biggest improvement comes from randomizing the location either by improving sbrk() or mmap(). Using mmap() for TCB gives some additional improvement that the area will be more or less separate from the other allocations. Analysis of the effect is complicated by the actual usage of randomize_va_space, either by kernel default setting, more importantly what the distros will actually use and finally the end users may be enlightened enough to change the setting. Also maximum randomization may be too aggressive for 32 bit architectures because of fragmentation of the virtual memory. If it could be mitigated by the kernel with a better sbrk entropy I would prefer than to add the tunable machinery on glibc. Also, tunables is not meant to be deployment mechanism on a security feature where the idea is to set if globally (and tunables also does not have a future-proof ABI). We might try to use a different strategy and replace sbrk call with mmap without adding a tunable, but it would add underlying mmap overhead so I am not sure if it should be a default option. The initial assessment seems that the overhead should be ok, but synthetic benchmark can be misleading. We would need more data of the expected extra overhead it might imposes (increase in mmap segments, performance on different workloads, multithread costs, etc). One option might a configure switch, which I am not very found as well (it increases maintainability costs).
On 4.12.2020 15.04, Adhemerval Zanella wrote: > > > On 04/12/2020 07:03, Topi Miettinen wrote: >> On 3.12.2020 22.33, Adhemerval Zanella wrote: >>> >>> >>> On 03/12/2020 13:05, Topi Miettinen via Libc-alpha wrote: >>>> On 3.12.2020 17.26, Rich Felker wrote: >>>>> On Thu, Dec 03, 2020 at 10:43:29AM +0200, Topi Miettinen wrote: >>>>>> On 3.12.2020 1.09, Rich Felker wrote: >>>>>>> On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha 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 the tunables system, malloc() and TCB >>>>>>>> use mmap() instead, except when instructed by tunable >>>>>>>> glibc.malloc.use_sbrk. >>>>>>> >>>>>>> The above description is contrary to present reality on Linux. With >>>>>>> kernel.randomize_va_space=2 (default), the brk area starts at a >>>>>>> randomize gap above end of data/bss. This is *stronger* ASLR than >>>>>>> mmap, which aside from the initial gap, generally appears just below >>>>>>> the previous map and thereby at a predictable offset from an anchor in >>>>>>> a shared library. >>>>>> >>>>>> Thanks for the review. I'd note that the randomization for brk is >>>>>> only 12 bits, so it's still relatively predictable. With >>>>>> randomize_va_space=3, the randomization provided by mmap() will be >>>>>> much better, the maximum allowed by the kernel design. The best in >>>>>> all cases would be if randomize_va_space=3 could be detected by libc >>>>>> and then it would change the default choice between brk() and mmap() >>>>>> automatically, or libc could generate a random address by itself and >>>>>> use mmap(random_addr,, MAP_FIXED_NOREPLACE) instead of brk(). For >>>>>> example, kernel could use aux vectors to pass the information. >>>>> >>>>> Why isn't the proposed randomize_va_space=3 kernel patch just >>>>> using a completely random base for brk region (and reserving at least >>>>> a few GB for it to grow into)? Then all existing programs would get >>>>> the benefit. >>>> >>>> Great idea! I'll try to add that to the patch set. >>> >>> Which the sbrk entropy increase, will mmap use on TCB allocation add >>> any security gain? >> >> I think the biggest improvement comes from randomizing the location either by improving sbrk() or mmap(). Using mmap() for TCB gives some additional improvement that the area will be more or less separate from the other allocations. Analysis of the effect is complicated by the actual usage of randomize_va_space, either by kernel default setting, more importantly what the distros will actually use and finally the end users may be enlightened enough to change the setting. Also maximum randomization may be too aggressive for 32 bit architectures because of fragmentation of the virtual memory. > > If it could be mitigated by the kernel with a better sbrk entropy I > would prefer than to add the tunable machinery on glibc. Also, tunables > is not meant to be deployment mechanism on a security feature where > the idea is to set if globally (and tunables also does not have a > future-proof ABI). > > We might try to use a different strategy and replace sbrk call with > mmap without adding a tunable, but it would add underlying mmap overhead > so I am not sure if it should be a default option. The initial > assessment seems that the overhead should be ok, but synthetic benchmark > can be misleading. We would need more data of the expected extra overhead > it might imposes (increase in mmap segments, performance on different > workloads, multithread costs, etc). > > One option might a configure switch, which I am not very found as well > (it increases maintainability costs). I've sent a new version (v8) of the kernel patch: https://lkml.org/lkml/2020/12/20/132 In that version, also heap (memory allocated with brk()) is randomized, including also lowest bits 11 to 4. Then malloc() on unmodified glibc and musl would be randomized on systems which enable randomize_va_space=3. For other systems, it would be good if the low bits of address of the heap would be randomized by the dynamic loader by calling sbrk() with a small (up to page size, aligned to 16 bytes) increment. Assuming that randomize_va_space=3 becomes mainstream (and the patch is accepted...), I think the new tunable for glibc and other changes to avoid sbrk() for TCB, dynamic loader and tunables aren't so interesting. It would be still good to use mmap() for malloc() since then all arenas would be separate from heap. Perhaps this could be selectable with mallopt() flag instead of a tunable? This could be also complemented by adding a small (aligned) random offset to the address given by mmap() for malloc() arenas. -Topi