linux-kernel - Re: [PATCH 0/2] jump label: update for .39

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]

Message-ID: <BLU0-SMTP44E52BF8FC82E66D2DA69596C80@phx.gbl>
Date:	Thu, 10 Mar 2011 16:14:31 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Jason Baron <jbaron@...hat.com>, peterz@...radead.org,
	hpa@...or.com, mingo@...e.hu, tglx@...utronix.de,
	andi@...stfloor.org, roland@...hat.com, rth@...hat.com,
	masami.hiramatsu.pt@...achi.com, fweisbec@...il.com,
	avi@...hat.com, davem@...emloft.net, sam@...nborg.org,
	ddaney@...iumnetworks.com, michael@...erman.id.au,
	linux-kernel@...r.kernel.org, Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: [PATCH 0/2] jump label: update for .39

* Steven Rostedt (rostedt@...dmis.org) wrote:
> On Thu, 2011-03-10 at 09:11 -0500, Mathieu Desnoyers wrote:
> > * Steven Rostedt (rostedt@...dmis.org) wrote:
> > > On Wed, 2011-03-09 at 15:47 -0500, Jason Baron wrote:
> > > > Hi,
> > > > 
> > > > Re-fresh of updates against latest -tip tree.
> > > 
> > > Thanks Jason,
> > > 
> > > I started looking at them, I should have comments tomorrow (if I have
> > > any comments ;)
> > > 
> > > > 
> > > > I've tried to split this update up somewhat, but I've only succeeded to split
> > > > out the dynamic debug bits. The interface changes and re-write are quite
> > > > intertwined.
> > > > 
> > > > I believe this update should address all the comments from the previous posting
> > > > except for Mathieu's request for a section of jump label pointers that point to
> > > > the jump label structures (since the compiler might leave gaps in the jump label
> > > > structures).
> > > 
> > > The jump label structures is a list of 3 pointers, correct? I doubt that
> > > gcc would place any holes in it as they are all aligned by natural word
> > > size.
> > > 
> > 
> > Hi Steven,
> > 
> > Can you explain what would prevent gcc from aligning these 3 pointers
> > (total of 24 bytes on 64-bit architectures) on 32-bytes ? Also, could
> > you point out what would refrain the linker from aligning the start of
> > object sections on the next 32-bytes (thus power of two) address
> > multiple ?
> 
> Maybe it would be just easier to add another long ;)
> 
> Seriously, it would. Then it would be 32 bytes on 64bit and 16 bytes on
> 32bit. Then I guess we can have our guarantee without doing a large
> change to have this indirect pointer and still waste sizeof(long) bytes
> in having it.
> 
> Just insert a long "Reserved" word.

I agree that this solution can work, but it's only because the
"object" definition is done in assembly in this case (and not in C, like
we did for trace event and tracepoints). Padding to power of 2 multiples
should make the linker happy. There should be a nice comment beside
these padding elements though.

Thanks,

Mathieu

> 
> -- Steve
> 
> > 
> > I think we need to be a bit more strict in our interpretation of what
> > guarantee gcc/ld provide and don't provide with respect to section and
> > structure alignment.
> > 
> > As it stands now, the section alignment of jump labels looks half-broken
> > on most architectures, and this *is* a big deal. I would really like to
> > see a patch for this (it can be a separate patch) going in for .39.
> > 
> > Thank you,
> > 
> > Mathieu
> > 
> 
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/