linux-kernel - Re: section breakage on ppc64 (aka _

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:	Sun, 3 Feb 2008 18:02:34 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: section breakage on ppc64 (aka __devinitconst is broken by design)

On Sun, Feb 03, 2008 at 06:26:35PM +0100, Sam Ravnborg wrote:
> On Sun, Feb 03, 2008 at 01:08:44PM +0000, Al Viro wrote:
> > ; cat >a.c <<'EOF'
> > const char foo[] __attribute__ ((__section__(".blah"))) = "";
> > const char * const bar __attribute__((__section__(".blah"))) = "";
> > EOF
> > ; gcc -m32 -S a.c
> > ; gcc -m64 -S a.c
> > a.c:2: error: bar causes a section type conflict
> > ;
> > 
> > That's 4.1.2 on ppc.  What happens is that the second declaration
> > wants to make .blah writable.  We actually trigger that in ppc64
> > builds on drivers/net/natsemi.c.
> > 
> > Note that on ppc64 without explicit sections you have the second one land in
> > .data.rel.ro.local, which is "aw",progbits.
> > 
> > The reason why it didn't visibly bite us before is that usually __devinit...
> > just expanded to nothing (unless you disable HOTPLUG, which requires
> > EMBEDDED, which wasn't apparently common enough for ppc64 builds).
> > 
> > Suggestions?
> 
> Hi Al.
> 
> __devinitconst were invented to cover this issue.
> So use __devinitconst for const data and 
> __devinitdata for non-const data.

As the example above shows, what is and what is not const data is
irrelevant.  The data _is_ const.  On ppc32 gcc is happy to put
it into read-only section.  On ppc64 the same version of gcc insists
on making the section this data object is going to *writable*.

> We recently had breakage in mainline with x86 64 bit
> (sis190) for the exact same case.

No, this is not exact same case.  Unfortunately.

> Does this work in your ppc example or do we need
> to find another solution?

Please, read the posted example.  s/.blah/.devinit.rodata/ if you wish - it's
not magical.  What happens is that
	* gcc choice of r/o vs. r/w section is not determined by object
being const
	* that choice is actually platform-dependent, even between related
platforms (see ppc32 and ppc64 in the example above).
--
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/