From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751761AbbJCGqn (ORCPT ); Sat, 3 Oct 2015 02:46:43 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:33513 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751367AbbJCGql (ORCPT ); Sat, 3 Oct 2015 02:46:41 -0400 Date: Sat, 3 Oct 2015 08:46:37 +0200 From: Ingo Molnar To: Paolo Bonzini Cc: Linus Torvalds , Dave Hansen , Kees Cook , "x86@kernel.org" , LKML , Linux-MM , Andrew Morton , Peter Zijlstra , Andy Lutomirski , Borislav Petkov Subject: Re: [PATCH 26/26] x86, pkeys: Documentation Message-ID: <20151003064637.GA23054@gmail.com> References: <55FF88BA.6080006@sr71.net> <20150924094956.GA30349@gmail.com> <56044A88.7030203@sr71.net> <20151001111718.GA25333@gmail.com> <560DB4A6.6050107@sr71.net> <560E6F5C.4040302@redhat.com> <560E7508.6080006@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560E7508.6080006@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Paolo Bonzini wrote: > > > On 02/10/2015 13:58, Linus Torvalds wrote: > > On Fri, Oct 2, 2015 at 7:49 AM, Paolo Bonzini 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