linux-kernel - Re: [RFC PATCH v2] media: Virtual camera driver

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: <aYE84i2GT5ntqZsO@kernel.org>
Date: Tue, 3 Feb 2026 02:10:10 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: linux-media@...r.kernel.org, jani.nikula@...ux.intel.com,
	anisse@...ier.eu, oleksandr@...alenko.name,
	linux-integrity@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Hans Verkuil <hverkuil@...nel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Jacopo Mondi <jacopo.mondi@...asonboard.com>,
	Ricardo Ribalda <ribalda@...omium.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2] media: Virtual camera driver

On Tue, Feb 03, 2026 at 12:50:06AM +0200, Sakari Ailus wrote:
> Hi Jarkko,
> 
> On Mon, Feb 02, 2026 at 10:44:21PM +0200, Jarkko Sakkinen wrote:
> > Already a quick Google survey backs strongly that OOT drivers (e.g.,
> > v4l2loopback) are the defacto solution for streaming phone cameras in
> > video conference calls, which puts confidential discussions at risk.
> 
> As I think it was pointed out in review comments for v1, the reason behind
> using v4l2loopback is the use of a downstream driver, which itself is a
> source of a security risk. If I understand correctly, supporting this
> (proprietary/downstream vendor drivers) would be the main use case this
> driver serves? Should this downstream driver be upstreamed to alleviate the
> security risks, the need for v4l2loopback or similar drivers presumably
> disappears.

My goal is not to proactively support proprietary drivers, and I don't
know how to measure such incentive or risk, when it comes to video
drivers.

And besides there is e.g. FUSE.

> 
> Another of the downsides of such proprietary/downstream solutions is they
> can never be properly integrated into the Linux ecosystem so functionality
> will remain spotty (limited to specific systems and specific releases of
> specific distributions) at best.
> 
> In other words, this driver appears to be orthogonal to solving either of
> the above two problems the proprietary/downstream solutions have.
> 
> From the Open Source libcamera based camera software stack point of view
> there doesn't seem to be a need for v4l2loopback or another similar driver.
> The two main reasons for this is that (1) there's no need for glueing
> something separate together like this and (2) V4L2 isn't a great
> application interface for cameras -- use libcamera or Pipewire instead.

While I get this argument isolated, it does not match the observed
reality, and does not provide tools to address the core issue. I
will be in my grave before I've fixed the world like you are
suggesting :-)

Like, first off, where would I use libcamera or Pipewire? There's
no well-defined target other than kernel in this problem.

> 
> > 
> > It can be also claimed that there's enough OOT usage in the wild that
> > possible security bugs could be considered as potential zerodays for the
> > benefit of malicious actors.
> > 
> > The situation has been stagnated for however many years, which is
> > unsastainable situation, and it further factors potential security
> > risks. Therefore, a driver is needed to address the popular use case.
> > 
> > vcam is a DMA-BUF backed virtual camera driver capable of creating video
> > capture devices to which data can be streamed through /dev/vcam after
> > calling VCAM_IOC_CREATE. Frames are pushed with VCAM_IOC_QUEUE and recycled
> > with VCAM_IOC_DEQUEUE. Zero-copy semantics are supported for shared DMA-BUF
> > between capture and output.
> > 
> > This enables efficient implementation of software, which can manage network
> > video streams from phone cameras, and map those streams to video devices.
> 
> I'd really try to avoid involving V4L2 in-kernel implementation when the
> source of the video is network. V4L2 is meant to be used (when it comes to
> video) for interfacing video related hardware such as cameras, ISPs and
> codecs. There are limited number of video output related devices, too, but
> network is something quite different from these.

I'd look at the usage patterns in the field too. It is pretty obvious
that there is a significant gap what users want and expect when it
comes to this debate.

> 
> -- 
> Kind regards,
> 
> Sakari Ailus

BR, Jarkko