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-next>] [day] [month] [year] [list]
Message-Id: <1228717226.13686.89.camel@sauron>
Date:	Mon, 08 Dec 2008 08:20:26 +0200
From:	Artem Bityutskiy <dedekind@...radead.org>
To:	Josh Boyer <jwboyer@...ux.vnet.ibm.com>
Cc:	linux-mtd@...ts.infradead.org, arnd@...db.de,
	LKML <linux-kernel@...r.kernel.org>,
	v4l-dvb-maintainer@...uxtv.org
Subject: Re: UBI/DVB ioctl conflict?

On Sun, 2008-12-07 at 09:58 -0500, Josh Boyer wrote:
> I received a bug report where someone noticed that the UBI ioctls can
> conflict with the dvb subsystem.  Looking it over, it seems that both
> subsystems use 'o' as the magic, and do have a set of somewhat
> conflicting sequence numbers as the secondary arg.
> 
> Is this a problem?

Hmm, thanks for noticing.

I've looked at this, and thankfully it looks like we were lucky and do
not use the same 'ioctl()' numbers, by chance.

Ioctl number has the following structure:

bits 0-15: command (or sequence number)
bits 16-29: parameter size
bits 30-31: mode (read, write, etc).

We have the following overlaps with DVB subsystem:

#define AUDIO_STOP   _IO('o', 1)
#define UBI_IOCRMVOL _IOW('o', 1, int32_t)

#define AUDIO_PLAY   _IO('o', 2)
#define UBI_IOCRSVOL _IOW('o', 2, struct ubi_rsvol_req)

#define AUDIO_PAUSE  _IO('o', 3)
#define UBI_IOCRNVOL _IOW('o', 3, struct ubi_rnvol_req)

These are fine because parameter sizes are different, and because UBI
uses _IOW and DVB uses _IO, so the mode bits are "01" and "00".

And:

#define FE_DISEQC_RECV_SLAVE_REPLY _IOR('o', 64,
                                        struct dvb_diseqc_slave_reply)
#define UBI_IOCATT _IOW('o', 64, struct ubi_attach_req)

#define FE_DISEQC_SEND_BURST _IO('o', 65)
#define UBI_IOCDET _IOW('o', 65, int32_t)

are also fine because parameter sizes are different and the mode bits
are different.

However, we have to be very careful in the future. It seems like DVB
has been in the kernel long before UBI, so this potential conflict
would be my fault.

Neither DVB nor UBI seem not to be documented in
Documentation/ioctl/ioctl-number.txt. Should we do this?

P.S. Added Arnd to CC for suggestions, as well as LKML and DVB
maintainers.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ