linux-kernel - Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64

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: <201205182158.59616.arnd@arndb.de>
Date:	Fri, 18 May 2012 21:58:59 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Daney <ddaney.cavm@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	"H.J. Lu" <hjl.tools@...il.com>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, mingo@...nel.org, tglx@...utronix.de
Subject: Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

On Friday 18 May 2012, H. Peter Anvin wrote:
> 
> On 05/18/2012 02:31 PM, Arnd Bergmann wrote:
> > 
> > However, in the kernel we always copy the fields one by one for compat
> > mode, even for the architectures that have identical layout between 32 and
> > 64 bit, and at least one libc implementation that I've seen (IIRC uClibc)
> > hardcodes the data structure to be the same as x86, with the padding
> > after the 'long', for all architectures. When I introduced the asm-generic
> > version of this, we had a discussion about whether we should try to use
> > the version with the "correct" padding but in the end decided to just use
> > the x86 version because that is what most big-endian architectures do
> > anyway.
> > 
> 
> Ouch.  Fail.  asm-generic should be about what is the right thing going
> forward.

But why do you think it's wrong the way it is? I see the idea of putting
padding in varying places depending on the endianess as a failed experiment
and defining a structure that is always the same as the logical conclusion
from that, even if it's a bit silly to have any padding in it at all.

Being consistent seems more important here than following the intent
of whoever came up with the concept of the ipc64 data structures
and was consequently ignored by most people after him.

If we really wanted the data structures to be compatible between 32 and
64 bit mode, we'd have to use __u64 here but that would mean having to
change all bits of user code that already rely on the existing x86
compatible layout.

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