From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 667EE17C21C; Tue, 3 Feb 2026 01:37:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770082625; cv=none; b=XDvq1lr228ew1baEHBRhPDR9ZSRppdw7QemyINkGnxBMs28U5Igrx9X5liph5LnmXa/Rr32yFtoJEsJzV2HJkESfQ9GKYbHAVnn6PtLBJQyH3HmFIBLPa9euJXB1onkrFRS+5ISs0e4sLu/SchYxnOe6tBF74C0O+b0DZIvT6gg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770082625; c=relaxed/simple; bh=lsBG7zzbmoTkrfdjUsoaqSHAHdiE50Ib5TMcrXd2GXs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TG/Kp1R7568pz3o5a86WNzKVDhGl/ACjMKJ5wjQl0ybJpc5LUCufiU/w6gTdD6A6DmAWMwy0hPGphBmL4oa3G1OwJluEi0/rNDMvnaJwSO9pozecJU/n7SvGeT1C78Tl9LT+jCfIQ1F7Dt9oUQp7AQbIO7ghubfol2kGTm1CiNE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PJJB5r1B; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PJJB5r1B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CDA6C116C6; Tue, 3 Feb 2026 01:37:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770082625; bh=lsBG7zzbmoTkrfdjUsoaqSHAHdiE50Ib5TMcrXd2GXs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PJJB5r1BPfzAqs1oT4H5rAAzADK+/6TsoVFpTm1GzM8sX12uTeun09/H6w8srwPn3 YdoC4saN0LD5abufm3iIZblHUziqNzI1LTgDpVQh/0I+dpYbh5wizWwNG8JSGEi1uU 50cr7V7zcJSQ39+lM5B61+ltxPlFqagf0exvHy7t4mIMW+Pf5bFL6VY+i2vHEr/xST FUcQ9BoIkujGTYt+flE2PZJWV61lj0Vh01J/wsTfaUW2Kz2d++T7OgF31WXMjSBqk9 oLmZgByyd3JZjp5ZaDaG12BFGpmkp6wgOkKpwxfdUYhxOMzX52OZq9raa/p/fDq0aT TUm290CNLVtXA== Date: Tue, 3 Feb 2026 03:36:59 +0200 From: Jarkko Sakkinen To: Sakari Ailus Cc: linux-media@vger.kernel.org, jani.nikula@linux.intel.com, anisse@astier.eu, oleksandr@natalenko.name, linux-integrity@vger.kernel.org, Mauro Carvalho Chehab , Hans Verkuil , Laurent Pinchart , Jacopo Mondi , Ricardo Ribalda , open list Subject: Re: [RFC PATCH v2] media: Virtual camera driver Message-ID: References: <20260202204425.2614054-1-jarkko@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Feb 03, 2026 at 02:10:15AM +0200, Jarkko Sakkinen wrote: > 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. As for the patch itself, it is RFC i.e., not request for immediate merge. I sent v2 quickly primarily to address the motivation part properly. I'll phase this down a bit, and rework on issues in the uAPI I observed (and remarked in a response to this patch) etc., and generally give people some time to digest. BR, Jarkko