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

Jason Gionta jjgionta at ncsu.edu
Wed Nov 19 14:13:42 UTC 2014


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.

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.

Anyway, I'm going to open a bug for LLVM to correctly handle the weak
symbols.

Thanks,

Jason

On Tue, Nov 18, 2014 at 9:37 PM, PaX Team <pageexec at freemail.hu> wrote:

> On 18 Nov 2014 at 23:23, Renato Golin wrote:
>
> > The _etext and _edata symbols seem to be implemented in many variants
> > of Unix, though I'm not sure that's in the ELF standard. It may just
> > be that Clang never had to deal with that before because it's only now
> > that we're compiling the kernel... :)
>
> _etext/_edata are usually defined by the linker script which in turn
> means that they're associated with whatever section they're defined
> after/in. for linux/x86 they're in arch/x86/kernel/vmlinux.lds.S and
> it seems that that llvm emits the weak symbols into different sections
> than gcc (e.g., .text.functionname vs. .text) that the linker script
> doesn't seem to take care of. iirc there used to be a catch-all inclusion
> of .text.* sections in .text but that was changed some years ago for
> supporting i-forget-what feature...
>
> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
>



-- 
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/20141119/194c58d2/attachment.html>


More information about the LLVMLinux mailing list