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: <x2xheosw24fecqjjv4fmj2t3i53k2ypyvmkkkvmv6xtdwsherd@e5klkm3ou4g7>
Date: Tue, 18 Nov 2025 15:09:16 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>, 
	Hans de Goede <hansg@...nel.org>, Mauro Carvalho Chehab <mchehab@...nel.org>, 
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 4/4] media: uvcvideo: Introduce allow_privacy_override

On Tue, Nov 18, 2025 at 06:14:09AM -0500, Greg Kroah-Hartman wrote:
> On Mon, Nov 17, 2025 at 08:14:19PM +0000, Ricardo Ribalda wrote:
> > Some camera modules have XU controls that can configure the behaviour of
> > the privacy LED.
> > 
> > Block mapping of those controls, unless the module is configured with
> > a new parameter: allow_privacy_override.
> 
> This is not the 1990's, please do not add new module parameters, they do
> not scale, nor work properly at all for modern hardware where you can
> have multiple devices in the same system.
> 
> This isn't an agreement that we should do this feature at all, just that
> if you do, it should NOT be a module parameter.

I agree with Greg: modprobe makes things harder specially on usb.

Also, in the specific case of privacy leds, IMO it should never be
possible to directly disable it, not even root via a modprobe or
runtime parameter.

Ok, as it might be some case where someone really wants to disable for his
special pet toy. If such cases are relevant, a Kconfig parameter could
be added (maybe depending on BROKEN), having privacy LED enabled by default. 

This way, any sane distro-generated Kernel should always have the privacy
LED on when camera is in use. 

On other words, if someone has secure boot enabled, he can be more confident
that a distro-vendor signed Kernel will honour the privacy LED, and not
even the root can tamper with - as BIOS access to disable secure boot would
be needed to change it - plus, booting a non-signed kernel.

Regards,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ