linux-kernel - Re: [patch -v2] flat: fix data sections alignment

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, 4 Mar 2009 15:00:25 -0500
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Johannes Weiner <jw@...ix.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	Russell King <rmk@....linux.org.uk>,
	Bryan Wu <cooloney@...nel.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Greg Ungerer <gerg@...inux.org>, linux-kernel@...r.kernel.org
Subject: Re: [patch -v2] flat: fix data sections alignment

On Wed, Mar 4, 2009 at 14:33, Johannes Weiner wrote:
> On Wed, Mar 04, 2009 at 01:04:00PM -0500, Mike Frysinger wrote:
>> On Wed, Mar 4, 2009 at 08:51, Johannes Weiner wrote:
>> > The flat loader uses an architecture's flat_stack_align() to align the
>> > stack but assumes word-alignment is enough for the data sections.
>> >
>> > However, on the Xtensa S6000 we have registers up to 128bit width
>> > which can be used from userspace and therefor need userspace stack and
>> > data-section alignment of at least this size.
>>
>> could this perhaps be a gcc problem ?  x86 has a similar problem with
>> sse and they addressed it with a function attribute.  after all, just
>> because your stack started out 128bit aligned doesnt mean gcc will
>> keep it that way when calling other functions.  so having the stack
>> start out aligned would only "fix" the stack for the application's
>> entry point right (which would in practice bubble up to main()) ?  so
>> you'd be right back where you started ...
>
> gcc generates sp changes only ever in multiples of 16 deltas, I just
> checked it again with various amounts of stack variables.
>
> The stack frames allocate themselves with an ENTRY instruction and the
> generated code I read here allocates stack frames of n * 16 bytes.
>
> So we are good to go as long as the initial stack frame is properly
> aligned.

throwing a few random cases at gcc isnt really a good way to validate.
 this would have worked for x86 too with older versions.  only when
common code in later gcc versions got more aggressive with stack
packing did people notice the issue.

so, lets look at the authoritative place: the gcc source code for xtensa

$ grep define.*STACK_BOUNDARY -B 2 gcc/config/xtensa/*.h
xtensa.h-/* Align stack frames on 128 bits for Xtensa.  This is necessary for
xtensa.h-   128-bit datatypes defined in TIE (e.g., for Vectra).  */
xtensa.h:#define STACK_BOUNDARY 128

ok, now i believe that forcing a stack alignment of 128bits in the
kernel is correct ;)
-mike
--
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/