linux-kernel - Re: kernel segv with 2.6.31-rc6 ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Aug 2009 19:01:13 -0400 (EDT)
From:	"John David Anglin" <dave@...uly1.hia.nrc.ca>
To:	James.Bottomley@...senPartnership.com (James Bottomley)
Cc:	deller@....de, rusty@...tcorp.com.au, linux-parisc@...r.kernel.org,
	linux-kernel@...r.kernel.org, dave.anglin@....ca, roland@...hat.com
Subject: Re: kernel segv with 2.6.31-rc6 ?

> On Thu, 2009-08-20 at 23:45 +0200, Helge Deller wrote:
> > On 08/20/2009 08:55 PM, John David Anglin wrote:
> > >> The reason seems to be, that something in the newer gcc compilers changed to generate multiple sections all named ".text" for the PCREL17 relocations.
> > >> Older compilers named those sections ".text.1", ".text.2", ".text.3" and so forth.
> > >
> > > GCC has never generated ".text.1", etc, on parisc linux as far as I know.
> > 
> > Hmm, I don't like to disagree with an gcc-expert like you,but
> > I did pasted an objdump in my last mail, which shows that gcc did
> > generated .text.1, .text.2 and so on:
> > 
> > Sections:
> > Idx Name          Size      VMA       LMA       File off  Algn
> >    0 .text         00000000  00000000  00000000  00000034  2**0
> >                    CONTENTS, ALLOC, LOAD, READONLY, CODE
> > ...
> >    4 .text.1       00000000  00000000  00000000  000000b0  2**0
> >                    CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> Since this is a relinked object, might it be possible that ld rather
> than gcc is the culprit?

I think it must be from binutils.  It might be a result of broken
section merging.  Possibly, we don't merge .text sections when
doing ld -r so that stub sections could be interleaved.  Alan Modra
wrote that code and I'm not that familiar with it.

The GCC definition of TEXT_SECTION_ASM_OP in pa-linux.h has never changed.
The PA backend in GCC doesn't play any section games on linux targets,
so it's hard to see how this could happen.  Check the assembler output
from GCC if you don't believe me.

At some time, GCC may start a new .text section at the beginning of
each function.  We do this on hpux but not linux.  This will cause
multiple .text sections to be present in an object and allow finer grained
stub placement.

Dave
-- 
J. David Anglin                                  dave.anglin@...-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/