RE: [RFC/PATCH v2 7/7] v4l: subdev: Generic ioctl support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>Laurent Pinchart wrote:
>Sent: Friday, July 09, 2010 5:32 PM
>To: linux-media@xxxxxxxxxxxxxxx
>Cc: sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
>Subject: [RFC/PATCH v2 7/7] v4l: subdev: Generic ioctl support
>
>Instead of returning an error when receiving an ioctl call with an
>unsupported command, forward the call to the subdev core::ioctl handler.
>
>Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
>---
> Documentation/video4linux/v4l2-framework.txt |    5 +++++
> drivers/media/video/v4l2-subdev.c            |    2 +-
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
>diff --git a/Documentation/video4linux/v4l2-framework.txt
>b/Documentation/video4linux/v4l2-framework.txt
>index 89bd881..581e7db 100644
>--- a/Documentation/video4linux/v4l2-framework.txt
>+++ b/Documentation/video4linux/v4l2-framework.txt
>@@ -365,6 +365,11 @@ VIDIOC_UNSUBSCRIBE_EVENT
> 	To properly support events, the poll() file operation is also
> 	implemented.
>
>+Private ioctls
>+
>+	All ioctls not in the above list are passed directly to the sub-device
>+	driver through the core::ioctl operation.
>+
>
> I2C sub-device drivers
> ----------------------
>diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-
>subdev.c
>index 31bec67..ce47772 100644
>--- a/drivers/media/video/v4l2-subdev.c
>+++ b/drivers/media/video/v4l2-subdev.c
>@@ -120,7 +120,7 @@ static long subdev_do_ioctl(struct file *file, unsigned
>int cmd, void *arg)
> 		return v4l2_subdev_call(sd, core, unsubscribe_event, fh, arg);
>
> 	default:
>-		return -ENOIOCTLCMD;
>+		return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
> 	}
>
> 	return 0;

Hi,
one remark about this:

(@Laurent: this is what've been discussing on Saturday on IRC)

It looks to me that with this, a subdev will only be able to have either
kernel or userspace-callable ioctls, not both. Note, that I don't mean one
ioctl callable from both, but 2 ioctls, where one is kernel-callable and
the other is userspace-callable. Technically that would work, but would
become a security risk. Malicious userspace would be able to call the
kernel-only ioctl.

So a driver has to be careful not to expose a node to the userspace if
it has kernel-callable subdev ioctls.

As long as drivers obey that rule and we do not require both types of
ioctls in one subdev, there is no problem.

Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center





--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux