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

Message-ID: <20131103194314.GB7376@thunk.org>
Date:	Sun, 3 Nov 2013 14:43:14 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Jason Cipriani <jason.cipriani@...il.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Correct parameter size for BLKSSZGET ioctl.

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/

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.

> 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)? On one
> hand, nothing seems particularly broken, per se, but on the other,
> "int" is vaguely defined and it is arguably only by chance (albeit a
> strong chance) that everything works (e.g. compilers used to build
> applications agree with compilers used to build the kernel).

Changing the parameters would result in an ABI change, which would
break programs.  So in general, it's generally not worth making these
changes.

For newer ioctls, in general we'll try to use specifically sized
types, mainly so that we don't need to do compat_ioctl handling to
support 32-bit binaries on a 64-bit kernel, but in general, it's
generally not worth changing existing ioctls.
						- Ted

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