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

Jason Gionta jjgionta at ncsu.edu
Tue Nov 25 15:33:19 UTC 2014

Thank you very much for your valuable insights. I was unaware of ftrace and
kprobes run-time modifications of kernel code so it's best to disregard my
write/vulnerability comment until I can test the issue further.

It seems from your comment that the actual bug might not lie with clang or
llvm but with the x86 linker script generated by the build

I have patched the LLVMLinker script to include the catch all *(.text.*). I
am not sure if this is the correct fix. Both ld.bfd and ld.gold produce the
same layout.

On Sat, Nov 22, 2014 at 7:10 AM, PaX Team <pageexec at freemail.hu> wrote:

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

Jason Gionta
Cyber Defense Lab
North Carolina State University
jjgionta at ncsu.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20141125/0e67d18b/attachment.html>

More information about the LLVMLinux mailing list