[PATCH] Add Safe-Linking to fastbins and tcache

[Adhemerval Zanella]

On 20/03/2020 23:47, Carlos O'Donell wrote:
> I like that we might extend Safe-Linking to all lists, including the
> exit_function_list which is a prime target of attack since it has
> a singly linked list and could be written to in order to execute
> arbitrary function pointers (requires also the probability of guessing
> PTR_MANGLE results). Unlike malloc, in other less performance
> sensitive functions we can use bits of randomness from a global
> variable.
> 
> Reviews so far:
> - Wilco Dijkstra (Arm)
> - DJ Delorie (Red Hat)
> - Adhemerval Zanella (Linaro)
> - Carlos O'Donell (Red Hat)
> 
> If Adhemerval, DJ, and Wilco want to give their Reviewed-by, then I'll
> add those too.

Ok, thanks.

> 
> I see one remaining issue to discuss and it is the emacs dumped heap
> state. The rest looks good to me too.
> 
> I'm TO'ing Florian here in case he wants to comment. A few years ago
> (time flies! 2016!) Florian had an idea to protect the chunk metadata
> with xor and some randomness (size and prevsize):
> https://sourceware.org/legacy-ml/libc-alpha/2016-10/msg00531.html

I forgot about this one.  With ASLR entropy we are bounded by two
factor: 

  1. architecture must provide ARCH_HAS_ELF_RANDOMIZE.
  2. the mmap entropy provided bits.

For 1. it seems not all architectures does provide it (based on
kernel Documentation/features/vm/ELF-ASLR/arch-support.txt with
some edits to remove architecture not support by glibc), which
makes this mitigation work solely on such architectures.

    -----------------------
    |         arch |status|
    -----------------------
    |       alpha: | TODO |
    |         arc: | TODO |
    |         arm: |  ok  |
    |       arm64: |  ok  |
    |        csky: | TODO |
    |        ia64: | TODO |
    |        m68k: | TODO |
    |  microblaze: | TODO |
    |        mips: |  ok  |
    |       nios2: | TODO |
    |      parisc: |  ok  |
    |     powerpc: |  ok  |
    |       riscv: |  ok  |
    |        s390: |  ok  |
    |          sh: | TODO |
    |       sparc: |  ok  |
    |         x86: |  ok  |
    -----------------------

(Linux internal documentation is in fact outdated, both sparc and
riscv does support ASLR).

Also, the mmap entropy vary largely over architectures and kernel
configurations, as table below where I extended the information 
compiled on BZ#22853 .  Some architectures also provides a kernel
config that can increase the maximum mmpa random bits (which is
only accessible by admin and system-defined).

  +-----------------+----------------+-------------------+
  | System          |  mmap rnd bits | MMAP_RND_BITS_MAX |
  +-----------------+----------------+-------------------+
  | x86_64          |        28      |            32     |
  | i386 / x32      |         8      |            16     |
  | arm             |         8 [2]  |            16 [3] |
  | aarch64         |        18 [4]  |            33 [5] |
  | powerpc64       |        14 [6]  |            29 [7] |     
  | powerpc         |         7 [8]  |            13 [9] |
  | s390x           |        11      |             -     |
  | s390            |        11      |             -     |
  | hppa            |        13      |             -     |
  | mips64          |        12      |            18     |
  | mips            |         8      |            15     |
  | riscv64         |        18      |            24     |
  | riscv32         |         8      |            17     |
  | sparc64         |        16      |             -     |
  | sparc32         |        11      |             -     |  
  +-----------------+----------------+-------------------+


So although this patch does help improve the situation, I think we should
move to a more robust and arch neutral way to obtain entropy for malloc
hardnening. 

Florian suggestion basically uses AT_RANDOM which provides 128-bits.
It is *way better* than rely on ASLR, but I am not sure if SHA256
the AT_RANDOM does improve things significantly, specially over the 
tradeoff of text and data increase on loader (on some architecture we 
might replace with hardware optimizations).

 [1] https://sourceware.org/pipermail/libc-alpha/2016-October/075546.html

 [2] 15 for 16k pages, and 14 for 64k pages.
 [3] 14 for PAGE_OFFSET=0x40000000 and 15 for PAGE_OFFSET=0x80000000.
 [4] 18 for 4k pages.
 [5] 19 for 36-bit VMA, 24 for 39-bit VMA, 27 for 42-bit VMA,
    30 for 47-bit VMA, 29 for 48-bit VMA / 64k pages, 31 for
    48-bit and 16k pages, 31 for 47-bit VMA / 4k pages, 14 for 64k
    pages, and 16 for 16k pages.
 [6] 18 for 4k pages.
 [7] 33 for 4k pages.
 [8] 5 for 256k pages, 9 for 16k pages, and 11 for 4k pages
 [9] 11 for 256k pages, 15 for 16k pages, and 17 for 4k pages.