[llvmlinux] Functions marked with __weak directives are linked in after the _etext symbol

PaX Team pageexec at freemail.hu
Sat Nov 22 12:10:13 UTC 2014


On 19 Nov 2014 at 9:13, Jason Gionta wrote:

> Thanks for the insight. This makes sense in terms of the ELF layout and
> section information. I see GCC correctly include .text.* sections into
> .text which is what brought up the question.

it's not gcc per se that controls the final layout but the linker and
in particular, the linker script used there. the default linker scripts
that come with binutils have something like this:

  .text           :
  {
    *(.text.unlikely .text.*_unlikely .text.unlikely.*)
    *(.text.exit .text.exit.*)
    *(.text.startup .text.startup.*)
    *(.text.hot .text.hot.*)
    *(.text .stub .text.* .gnu.linkonce.t.*)
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
  }

(excerpt from /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/ldscripts/elf_x86_64.x)

as you can see, there's the catch-all .text.* in there. the linker script
of linux (the kernel) overrides the default linker script and it doesn't
seem to have this catch-all clause.

> What is interesting is I am seeing strange things happen to the memory
> allocated/mapped after the _etext symbol that can potentially lead to a
> vulnerability caused by double mapping physical pages. Some memory after
> the _etext is mapped RX (e.g., non-writable). However, I am later seeing
> writes occurring to physical pages of the RX memory.

i think you're describing two (potential) problems here:

1. weak functions emitted outside (after) the kernel's .text section that
   as a consequence may not be mapped as executable (and trigger an oops
   when called at runtime)

2. writes to read-only memory

the first problem can manifest on archs that take care of proper kernel
image access rights at runtime, e.g., on x86 DEBUG_SET_MODULE_RONX and
DEBUG_RODATA attempt to do so. this can arguably blamed on the compiler
but i'd also say that the kernel('s linker script) should also take care
of such extra sections. from what i recall, the ksplice related back in
2007-2008 or so attempted to clean up kernel section handling, not sure
why the catch-all clause slipped by as IIRC they also rely on
-ffunction-sections that produces similar sections for normal functions.

as for the second problem, it depends on what kind of writes you're seeing.
the kernel can patch itself at runtime via the alternatives mechanism, and
there's kprobes, ftrace, etc that can result in modifications to otherwise
read-only code. if you have more details that suggest there's a vulnerability
here then you should probably post that to lkml instead ;).



More information about the LLVMLinux mailing list