linux-kernel - Re: [PATCH 1/3] module: deal with alignment issues in built-in module versions

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Feb 2011 13:54:57 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
Cc:	dtor@...are.com, linux-kernel@...r.kernel.org,
	geert@...ux-m68k.org, rusty@...tcorp.com.au,
	linux-m68k@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/3] module: deal with alignment issues in built-in module versions

On Thu, Feb 17, 2011 at 1:17 PM, David Miller <davem@...emloft.net> wrote:
>> EVERY SINGLE OF YOUR ARGUMENTS WORK FOR "pointer" TOO!
>
> It at least will not happen at the current time, because GCC only
> plays these games on aggregates.

So? Do they actually promise to never do it for pointers? What makes
aggregates so special? Rather than just happenstance?

I wouldn't be surprised if the structure alignment isn't even about
something even subtler and totally random, like size of structure (ie
"don't align small structures")

> Also, for exception tables, we've avoided this problem because
> we emit the exception tables by hand using inline asm and therefore
> explicitly control all aspects of the alignment and size.

.. and maybe that's the right thing to do here too.

> The GCC manual even documents the alignment attribute behavior.

The gcc manual is worthless. Every time some gcc person wants to
change behavior, they just change the manual. So you can't rely on it
anyway. We've seen that with inline asm before etc.

> Also, please don't shoot the messenger, I didn't make GCC behave this
> way but I doubt you'll have any luck undoing this behavior in the
> tools which therefore means as pragmatists we have to handle it one
> way or another.

I'm shooting not the messenger, but the people who make these kinds of
really ugly changes with bad changelogs that don't even explain what
the actual problem is. And apparently any gcc person is free to break
it in the future _anyway_.

Is there a -fdata-align or something? Or would __attribute__((packed))
help? Something that explicitly tells gcc "don't do this", instead of
"let's add indirection and hope gcc doesn't add alignment for _that_".
Especially as the extra pointer makes the code even uglier.

And if we do have to use the pointer thing, let's at least then do the
pointer with asms, so that gcc _really_ can't screw it up. Rather than
just move the potential bug around.

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