lkml.org 
[lkml]   [2015]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 26/26] x86, pkeys: Documentation

* Paolo Bonzini <pbonzini@redhat.com> wrote:

>
>
> On 02/10/2015 13:58, Linus Torvalds wrote:
> > On Fri, Oct 2, 2015 at 7:49 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >> On 02/10/2015 00:48, Linus Torvalds wrote:
> >>> It's quite likely that you will find that compilers put read-only
> >>> constants in the text section, knowing that executable means readable.
> >>
> >> Not on x86 (because it has large immediates; RISC machines and s390 do
> >> put large constants in the text section).
> >>
> >> But at the very least jump tables reside in the .text seection.
> >
> > Yes, at least traditionally gcc put things like the jump tables for
> > switch() statements immediately next to the code. That caused lots of
> > pain on the P4, where the L1 I$ and D$ were exclusive. I think that
> > caused gcc to then put the jump tables further away, and it might be
> > in a separate section these days - but it might also just be
> > "sufficiently aligned" that the L1 cache issue isn't in play any more.
> >
> > Anyway, because of the P4 exclusive L1 I/D$ issue we can pretty much
> > rest easy knowing that the data accesses and text accesses should be
> > separated by at least one cacheline (maybe even 128 bytes - I think
> > the L4 used 64-byte line size, but it was sub-sections of a 128-byte
> > bigger line - but that might have been in the L2 only).
> >
> > But I could easily see the compiler/linker still putting them in the
> > same ELF segment.
>
> You're entirely right, it puts them in .rodata actually. But .rodata is
> in the same segment as .text:
>
> $ readelf --segments /bin/true
> ...
> Section to Segment mapping:
> Segment Sections...
> 00
> 01 .interp
> 02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym
> .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init
> .plt .text .fini .rodata .eh_frame_hdr .eh_frame
> 03 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .data .bss
> 04 .dynamic
> 05 .note.ABI-tag .note.gnu.build-id
> 06 .eh_frame_hdr
> 07
> 08 .init_array .fini_array .jcr .data.rel.ro .dynamic .got

Is there an easy(-ish) way (i.e. using compiler/linker flags, not linker scripts)
to build the ELF binary in such a way so that non-code data:

.rodata .eh_frame_hdr .eh_frame

... gets put into a separate (readonly and non-executable) segment? That would
enable things from the distro side AFAICS, right?

(assuming I'm reading the ELF dump right.)

Or does this need binutils surgery?

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-10-03 09:21    [W:0.070 / U:0.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site