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] [day] [month] [year] [list]
Message-ID: <CANiDSCtZw48bHc7m7aVPX8jFubkPYc-NKXtcWg1_rdiCMVXLnw@mail.gmail.com>
Date: Tue, 18 Nov 2025 19:30:50 +0100
From: Ricardo Ribalda <ribalda@...omium.org>
To: Gergo Koteles <soyer@....hu>
Cc: Hans de Goede <hansg@...nel.org>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, 
	Mauro Carvalho Chehab <mchehab@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-usb@...r.kernel.org
Subject: Re: [PATCH 4/4] media: uvcvideo: Introduce allow_privacy_override

Hi Gergo

On Tue, 18 Nov 2025 at 16:36, Gergo Koteles <soyer@....hu> wrote:
>
> Hi Hans,
>
> On Tue, 2025-11-18 at 15:26 +0100, Hans de Goede wrote:
>
> >
> > > > Do you have a compelling use-case for turning off the privacy LED?
> > > >
> > >
> > > As a pet camera, it is useful to be able to turn off the LED.
> > > In some cases, it can also eliminate unwanted reflections.
> > > Some cameras may have blue LED, and if someone hates blue LEDs..
> >
> > And almost all cameras already do not allow manually overriding the LED
> > turning on while streaming. There is a very low-tech solution for this,
> > put some black isolation tape over the LED :)
> >
>
> Yes, this is also a good and stable solution. :)
>
> > > > My core goal is simple: if the camera is in use, the privacy LED must
> > > > be ON. If the LED is ON unexpectedly, it serves as a clear indication
> > > > that something unusual is happening.
> >
> > ...
> >
> > > > No freedom is lost. This change simply increases the
> > > > trustworthiness/reliability of your device.
> > >
> > > It will decrease to the extent that fewer people will know that such an
> > > option exists because they will not read the description of the
> > > module's parameters.
> >
> > People currently already will not know that the option exists.
> >
> > Seeing the current LED controls on Logitech cams requires 2 manual steps:
> >
> > 1. Install uvcdynctrl which maps the custom GUIDs to the LED controls
> >    Note distros do not install this be default
> > 2. Use either a GUI v4l2-control app like qv4l2ucp or gtk-v4l, or
> >    v4l-ctrl -l to list controls and then change the setting.
> >
> > So there already is close to 0 discoverability for this Logitech
> > only feature.
>
> This is not completely true.
> The cameractrls uses these extensions and controls with
> uvc_xu_control_query() and has over 140k downloads on Flathub alone.
>
> >
> > For the new MIPI cameras on laptops we have deliberately made it
> > impossible to disable the privacy LED while streaming even though
> > it is often controlled by a separate GPIO because of privacy reasons.
> >
> > For the same privacy reasons I fully agree with Ricardo that this should
> > be behind a module option. Which replaces step 1. with creating
> > a /etc/modprobe.d/uvc.conf file, so just about as much work.
> >
>
> I agree that this will be useful. The module parameter is also simpler
> than per-V4L2 control permission management. And the latter is not
> needed in other cases, I think.
>
> However, if allow_privacy_override is enabled, would it be worth
> mapping these controls by the kernel?
> So uvcdynctrl or cameractrls would not be needed for this control.

If allow_privacy_override is enabled and there is a standard control
in include/uapi/linux/v4l2-controls.h that supports such control: I
have no issue adding the mapping for it.

Right now we only have V4L2_CID_PRIVACY which is a boolean and has
usually been used to tell if the privacy shutter is on or off, not to
configure the LED.

In any case, the default value of allow_privacy_override should be
false. I would even argue that the best approach is to block all the
known LED config controls after a deprecation period.
Check: https://lore.kernel.org/linux-media/CANiDSCuv8UG6TMx6pK348okK+NYzAorPEgPYzoRCEZiBDgPP=A@mail.gmail.com/

> >
>
> Regards,
> Gergo



-- 
Ricardo Ribalda

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ