linux-kernel - Re: [v4l-dvb-maintainer] Re: [PATCH] V4L: struct video

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: <Pine.LNX.4.58.0607171650510.18488@shell3.speakeasy.net>
Date:	Mon, 17 Jul 2006 17:25:38 -0700 (PDT)
From:	Trent Piepho <xyzzy@...akeasy.org>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
cc:	Robert Fitzsimons <robfitz@...k.net>,
	Andrew Morton <akpm@...l.org>,
	Linux and Kernel Video <video4linux-list@...hat.com>,
	76306.1226@...puserve.com, fork0@...nline.de, greg@...ah.com,
	linux-kernel@...r.kernel.org,
	"Randy.Dunlap" <rdunlap@...otime.net>,
	v4l-dvb maintainer list <v4l-dvb-maintainer@...uxtv.org>,
	shemminger@...l.org
Subject: Re: [v4l-dvb-maintainer] Re: [PATCH] V4L: struct video_device
 corruption

On Sat, 15 Jul 2006, Mauro Carvalho Chehab wrote:
> Em Sáb, 2006-07-15 às 23:08 +0000, Robert Fitzsimons escreveu:
> > The layout of struct video_device would change depending on whether
> > videodev.h (V4L1) was include or not before v4l2-dev.h, which caused
> > the structure to get corrupted.
> Hmm... good point! However, I the proper solution would be to trust on
> CONFIG_VIDEO_V4L1_COMPAT or CONFIG_VIDEO_V4L1 instead. it makes no sense
> to keep a pointer to an unsupported callback, when V4L1 is not selected.

It's not so clear that the problem is with v4l2-dev.h, because if you look
that file:

#ifdef CONFIG_VIDEO_V4L1
#include <linux/videodev.h>
#else
#include <linux/videodev2.h>
#endif

linux/videodev.h is where HAVE_V4L1 is defined (always).  So, if
CONFIG_VIDEO_V4L1 is set, then HAVE_V4L1 must also bet set.

I think that the real problem is that many drivers include the V4L1 API
file videodev.h when V4L1 is NOT on.  Should drivers be providing V4L1 API
functions, or need anything from videodev.h, if V4L1 is not on?

It seems like they either need to depend on VIDEO_V4L1 or only include the
V4L1 API header file when V4L1 is turned on.  Which also means they would
need to #ifdef out any V4L1 code when V4L1 is turned off.  The bttv driver
for example does not do this.  It includes a bunch of V4L1 functions even
when V4L1 (and V4L1_COMPAT) are turned off.

BTW, I think the CONFIG_VIDEO_V4L1 check in v4l2-dev.h should instead check
for CONFIG_VIDEO_V4L1_COMPAT.  For example, cx88-video.c includes
videodev.h when CONFIG_VIDEO_V4L1_COMPAT is turned on.
-
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/