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: <4FB597F3.3060909@gmail.com>
Date:	Thu, 17 May 2012 17:29:39 -0700
From:	David Daney <ddaney.cavm@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 05/17/2012 05:14 PM, H. Peter Anvin wrote:
> On 05/17/2012 05:07 PM, Linus Torvalds wrote:
>> On Thu, May 17, 2012 at 4:51 PM, H. Peter Anvin<hpa@...or.com>  wrote:
>>>
>>> The sane thing would seem to be to change __BITS_PER_LONG to 32 on x32
>>> and fix the padding hacks in struct shmid64_ds; H.J., would you agree?
>>
>> Ugh. That looks like a disaster.
>>
>> The padding hacks that depend on __BITS_PER_LONG seem pretty damn broken anyway.
>>
>> They only work if the kernel agrees with the value (which is against
>> the whole point of making __BITS_PER_LONG be about some user-level ABI
>> thing) or for little-endian machines.
>>
>> IOW, all the __BITS_PER_LONG games look totally broken to me. I can't
>> see how they could possibly even be fixed.
>>
>
> Well, on existing compat (e.g. i386) __BITS_PER_LONG is definitely not
> the same as kernel.  And yes, I don't see how the heck this was ever
> correct on bigendian machines or even for compat in any form (if the
> kernel tries to interpret the extra bits and user space didn't
> initialize them we're lost.)
>
> The "logical" thing to do here seems to just use __s64, but I have no
> idea if that would suddenly break bigendian architectures...
>
> David, Ralf, do you have any idea what e.g. MIPS does here?

At the top of arch/mips/include/asm/types.h we have:

#ifdef __KERNEL__
# include <asm-generic/int-ll64.h>
#else
# if _MIPS_SZLONG == 64
#  include <asm-generic/int-l64.h>
# else
#  include <asm-generic/int-ll64.h>
# endif
#endif

In this case the userspace gcc will define _MIPS_SZLONG according to the 
selected ABI.

in arch/mips/include/asm/bitsperlong.h we have:

#define __BITS_PER_LONG _MIPS_SZLONG

Again, the proper value for the userspace ABI.

This is either 32 or 64 depending which of the three userspace ABIs are 
selected.

I don't know if that answers your question though.

My preference would be that any type that has a width that varies by 
userspace ABI, not include "64" or "32" within its name.

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