linux-kernel - Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a subdevice

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: <2fd9053f-34b6-4e97-a898-98fd71a485e8@xs4all.nl>
Date: Sun, 10 Nov 2024 11:29:28 +0100
From: Hans Verkuil <hverkuil@...all.nl>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
 Ricardo Ribalda <ribalda@...omium.org>
Cc: Hans de Goede <hdegoede@...hat.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, Yunke Cao <yunkec@...omium.org>
Subject: Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a
 subdevice

On 10/11/2024 11:02, Mauro Carvalho Chehab wrote:
> Em Sat, 9 Nov 2024 17:29:54 +0100
> Ricardo Ribalda <ribalda@...omium.org> escreveu:
> 
>>>
>>> I think that should sort the issue, assuming that 1. above holds true.
>>>
>>> One downside is that this stops UVC button presses from working when
>>> not streaming. But userspace will typically only open the /dev/video#
>>> node if it plans to stream anyways so there should not be much of
>>> a difference wrt button press behavior.  
>>
>> I do not personally use the button, but it is currently implemented as
>> a standard HID device. 
> 
> IMO, controlling the privacy via evdev is the best approach then. There's
> no need for a RW control neither at subdev or at device level. It could
> make sense a Read only to allow apps to read, but still it shall be up to
> the Kernel to protect the stream if the button is pressed.
> 
>> Making it only work during streamon() might be
>> a bit weird.
>> I am afraid that if there is a button we should keep the current behaviour.
> 
> Privacy matters only when streaming. IMO the Kernel check for it needs to
> be done at DQBUF time and at read() calls, as one can enable/disable the
> camera while doing videoconf calls. I do that a lot with app "soft" buttons,
> and on devices that physically support cutting the video. 

We could add a vb2_s_privacy(bool privacy) function to vb2 to tell vb2 if the privacy
mode is on. And if so, take action. E.g. calling QBUF/DQBUF would return a -EACCES error.

That will ensure consistent behavior for all drivers that have a privacy function.

Note that there are two types of privacy GPIO: one that triggers when a physical
cover is moved, blocking the sensor, and one that is a button relying on software
to stop streaming video. In the first case it is informative, but you can keep
streaming.

Regards,

	Hans

> 
> I don't trust myself privacy soft buttons, specially when handled in userspace,
> so what I have are webcam covers (and a small stick glued at a laptop camera
> that has a too small sensor for a webcam cover). I only remove the cover/stick
> when I want to participate on videoconf with video enabled with the builtin
> camera.
> 
> Regards
> 
> Thanks,
> Mauro
>