linux-kernel - Re: Please include const-sections into linux-next

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:	Wed, 19 Oct 2011 11:21:21 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: Please include const-sections into linux-next

On Wed, 2011-10-19 at 18:15 +0200, Andi Kleen wrote:
> On Wed, Oct 19, 2011 at 10:54:23AM -0500, James Bottomley wrote:
> > 
> > > One alternative to track it down would be to apply the attached
> > > patch to the gcc, then gcc would print it out.
> > 
> > I think the basic problem that excites the toolchain somehow is
> > sectional annotations.  Can't we just dump them and do it all in a
> 
> We already use these annotations all over. Just currently they mess up
> the 'r' and 'w' bits on the sections because a few (not the majority)
> of declarations mismatch the ro vs rw sections.  My patchkit was just trying
> to fix up those that were wrong
> 
> So you should be already using them.
> 
> Just need to find out what triggers your toolchain with these changes.
> I suspect it's some kind of toolchain bug.

I think I've already said 3 times that I think it's some kind of
toolchain bug.  The problem is it's likely in all the non-x86
toolchains.

> > linker script?  Linker scripts seem to be much better tested.
> 
> The linker script just declares the order of the section. 
> The attributes are a union of what the compiler declares.
> To dump them I just use objdump --section-headers or
> readelf -a usually.

OK, look at it another way: why do we need the type annotations?  I
think it's only for section conflict checking, right?  If the compiler
gets it wrong anyway, why not just dump all the type annotations, then
it should have no type conflicts (spurious or otherwise) to complain
about.  We already have link time section checking scripts (they're the
useless ones that complain about section mismatches in dev annoations)
so why not put them to work to make up for compiler deficiencies?

James


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