linux-kernel - Re: Correct parameter size for BLKSSZGET ioctl.

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] [day] [month] [year] [list]

Message-Id: <1385315502.1974.283@driftwood>
Date:	Sun, 24 Nov 2013 11:51:42 -0600
From:	Rob Landley <rob@...dley.net>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Jason Cipriani <jason.cipriani@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Correct parameter size for BLKSSZGET ioctl.

On 11/03/2013 01:43:14 PM, Theodore Ts'o wrote:
> On Sun, Nov 03, 2013 at 02:07:56PM -0500, Jason Cipriani wrote:
> >
> > There was a bigger question hidden behind the context there that I'm
> > still wondering about: Are these ioctl interfaces specified and
> > documented somewhere? From what I've seen, and from your response,  
> the
> > implication is that the kernel source *is* the specification, and  
> not
> > document exists that the kernel is expected to comply with; is this
> > the case?
> 
> The kernel source is the specification.  Some of these ioctl are
> documented as part of the linux man pages, for which the project home
> page is here:
> 
>      https://www.kernel.org/doc/man-pages/

Specifically "man ioctl_list"

> However, these document existing practice; if there is a discrepancy
> between what is in the kernel has implemented and the Linux man pages,
> it is the Linux man pages which are buggy and which will be changed.
> That is man pages are descriptive, not perscriptive.

Although if something obvious is missing or wrong, it's nice to ping  
Michael Kerrisk so he can update it.

> > Secondly, would it not make sense to change all ints in all public
> > kernel interfaces to data types with a well-defined, machine- and
> > (mostly) compiler-independent size, e.g. int32_t (or whatever)?

Allow me to introduce you to the LP64 specification, which Linux, BSD,  
and MacOS X all adhere to:

http://www.unix.org/whitepapers/64bit.html
http://www.unix.org/version2/whatsnew/lp64_wp.html

It says that char is 8 bits, short is 16 bits, int is 32 bits, and long  
is the same size as a pointer (32 bits on 32 bit platforms, 64 bits on  
64 bit platforms). There's a de-facto "long long is 64 bits" assumption  
in fairly widespread use, but it's not explicit in the standard.

(Welcome to the 21st century, where we know what sizes our data types  
are even _without_ c99.)

Rob

P.S. The insane legacy reasons that Windows does _not_ adhere to this  
standard are documented at:

http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

(So if you're wondering why qemu has "pointer sized int" typedefs in  
its' source, it's because they care about running on windows. And even  
if you did care about that, you can still rely on the sizes of char,  
short, and int.)--
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/