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: <CA+55aFzfku-5qgVPahu27DLz-y8MUmh7Mw9sq_TyO49Zb0tg=A@mail.gmail.com>
Date:	Thu, 17 May 2012 21:05:24 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H.J. Lu" <hjl.tools@...il.com>
Cc:	"H. Peter Anvin" <hpa@...nel.org>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, mingo@...nel.org, tglx@...utronix.de,
	Paul Mundt <lethal@...ux-sh.org>,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

On Thu, May 17, 2012 at 8:59 PM, H.J. Lu <hjl.tools@...il.com> wrote:
>
> But __BITS_PER_LONG used in kernel header files really
> means "long" as seen by kernel, not by user space.

No, hjl, no it does NOT.

That might be what we'd all *wish* it did, but it's not at all what it does.

What it actually means is "how many bits in a long as it is being
compiled right now".

User code headers have absolutely *no* idea what the size "long" the
kernel was compiled with. You'd have to do an "uname()" system call to
figure that out, and even then you shouldn't be sure if the kernel is
just really good at compatibility mode.

Just look at the code. It literally sets __BITS_PER_LONG depending on
*compiler* flags like __s390x__ etc. Which depend on things like
"-m32" etc as done in user space.

When those same headers are compiled *as*part*of*the*kernel*, then -
and only then - does __BITS_PER_LONG hopefully match what the kernel
"long" is. But that is kind of irrelevant, because if this was purely
a kernel issue, we would use the non-underscore version (ie just
"BITS_PER_LONG") which is *only* for the kernel, and not exported to
user space at all.

                      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/