On Wed, Nov 30, 2022 at 06:07:51PM +0200, Andy Shevchenko wrote: > On Wed, Nov 30, 2022 at 05:20:11PM +0200, Laurent Pinchart wrote: > > On Wed, Nov 30, 2022 at 02:52:50PM +0000, Sakari Ailus wrote: > > > On Wed, Nov 30, 2022 at 02:56:46PM +0100, Hans de Goede wrote: > > ... > > > > The privacy LED is separate from sensor, including its power on/off > > > sequences which suggests it could be at least as well be handled > > > separately. > > > > And if the privacy LED is controllable through a GPIO, I think it should > > be turned on at stream on time, not at power on time. That would allow > > things like reading the OTP data from the sensor without flashing the > > privacy LED. > > The malicious software may power up camera and drive it via user space / > separate code flow in the kernel, no? With correctly written drivers, there should be no way to power up the camera from userspace through the V4L2 API without starting streaming. Also, programming the camera sensor won't be enough to capture images, you need to deal with all the other camera-related IP cores which are controlled through V4L2, and doing so will start streaming in the camera sensor driver through the normal API anyway. > I would stick with power on as it's the most secure side. Even if we 100% know > we are _not_ streaming this LED should indicate that it may be turned on at any > time, no? Ideally, the privacy LED should be controlled automatically by the hardware without software intervention, and should be wired to a camera streaming signal. In many cases it's wired to the power rails instead, which is extremely annoying. I'd rather avoid this annoyance when the LED is GPIO-controlled. -- Regards, Laurent Pinchart
