linux-kernel - Re: [PATCH] ptrdiff_t is not uintptr

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: <200708192117.00759.david-b@pacbell.net>
Date:	Sun, 19 Aug 2007 21:17:00 -0700
From:	David Brownell <david-b@...bell.net>
To:	Al Viro <viro@....linux.org.uk>
Cc:	Satyam Sharma <satyam@...radead.org>,
	Anton Altaparmakov <aia21@....ac.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ptrdiff_t is not uintptr_t, damnit

On Sunday 19 August 2007, Al Viro wrote:
> On Sun, Aug 19, 2007 at 08:26:24PM -0700, David Brownell wrote:
> 
> > ISTR the warning was the other way around:   about "cast from integer
> > to pointer of a different size".  The __u64 came from userspace and
> > the kernel pointer was only 32 bits.  Not really truncation, but GCC
> > could not know that directly ... ergo the extra non-pointer cast.
> 
> And?  Cast to integer type with the size equal to that of pointer.
> unsigned long is just that on all supported targets.

Some tool kept warning about that.  Presumably then-current sparse.
I've certainly heard the conventional "unsigned long fits pointers"
wisdom, but tools disagreed.  (Does ANSI C guarantee that?  I'd think
not, or uintptr_t would not be needed.)

And ptrdiff_t was the closest relevant data type that passed both
gcc and sparse, since uintptr_t didn't previously exist everywhere.

> More interesting question is whether you want an error returned when
> pointers are 32bit and value doesn't fit into that...

Either access_ok() or copy_from_user() reports an error if the
pointer part of that u64 (N LSBs) is bad.

As a general policy, I think the other part is undefined and
irrelevant to the kernel ... it's a kind of explicit padding,
and padding isn't valdated.  (At most it's zeroed to prevent
a covert channel, but that's not relevent here.)

- Dave

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