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] [day] [month] [year] [list]

Message-Id: <47AC2C1F.76E4.0078.0@novell.com>
Date:	Fri, 08 Feb 2008 09:17:03 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Sam Ravnborg" <sam@...nborg.org>
Cc:	"Chuck Ebbert" <cebbert@...hat.com>,
	<linux-kernel@...r.kernel.org>, "Al Viro" <viro@...IV.linux.org.uk>
Subject: Re: section breakage on ppc64 (aka __devinitconst is broken by
	design)

>Al posted the following:
>====================================================================
>; 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.
>====================================================================
>
>Se we see that despite being marked as const the the section
>is in one case marked as read-only by gcc and in another case the section
>is marked as rw.

Oh, indeed, this kind of a construct also fails for ia64 on existing gcc-s.

>And this is with the gcc version that is in use today and which
>we must support.
>Thats why I think we have to loose the constification that is going on
>or we should loose the section attribute on the data.

That is very unfortunate, but is then a good reason to fold the
'const' into the __devinitconst definition as I originally suggested (and
perhaps that's the reason why I didn't have problems with my version
of the patch on ia64) - that way, those architectures that can't tolerate
it could have __devinitconst continue to resolve to __devinitdata,
resulting in traditional section allocation, while targets like x86 can still
benefit from the constification.

Apart from that we may want to approach the gcc folks to allow a way
to override this 'optimization for the kernel (or more generally for
statically linked executables).

Jan

--
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/