linux-kernel - Re: ioctl's suck?

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

Message-ID: <48950B8F.70602@shaw.ca>
Date:	Sat, 02 Aug 2008 19:36:15 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Brian Beattie <beattie@...ttie-home.net>
CC:	linux-kernel@...r.kernel.org
Subject: Re: ioctl's suck?

Brian Beattie wrote:
> The other day Linus (I think) made the statement, that I don't disagree
> with, that I will parapharse as "ioctl's suck".  If I recall correctly
> and understand he was saying that a device that uses ioctls is broken.
> (this is my paraphrase and if it offends anybody it is my fault not the
> original author's).
> 
> This got me to thinking about a device driver that I'm working on.
> Currently I have some ioctls to handle status and out of band messages
> and I'm wondering about eliminating the ioctls.  I'm wondering if
> anybody has any ideas or opinions that they would like to share, about
> just what i wrong with ioctls and/or how to avoid them.

As I see it the main problems are:

-Unless the ioctl parameter structures are laid out carefully, you end 
up with problems like different structure layouts between 32/64-bit 
processes, etc.

-They can't really be used by anything other than a C or C++ program. 
Anything else (shell script, Python, Java, etc.) is pretty much out of 
luck unless it can use a C shim layer of some sort.

> 
> I can see a number of problems with ioctls that I can'tr quite put into
> words.
> 
> I could add a control device and pass ascii strings for status and OOB
> messages, would that be an improvement?

Quite likely. For something like a status that's being read out of the 
device, a sysfs file would seem a more logical choice. If you're sitting 
there waiting for messages to show up, though, a separate device node 
might be better.
--
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/