linux-kernel - Re: [PATCH v5] platform/x86: add lenovo wmi camera button driver

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: <Ze08hwqt9fNMFQa8@google.com>
Date: Sat, 9 Mar 2024 20:52:23 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Armin Wolf <W_Armin@....de>
Cc: 艾超 <aichao@...inos.cn>,
	hdegoede <hdegoede@...hat.com>,
	"ilpo.jarvinen" <ilpo.jarvinen@...ux.intel.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	platform-driver-x86 <platform-driver-x86@...r.kernel.org>,
	linux-input@...r.kernel.org
Subject: Re: [PATCH v5] platform/x86: add lenovo wmi camera button driver

On Fri, Mar 08, 2024 at 05:15:48PM +0100, Armin Wolf wrote:
> Am 08.03.24 um 09:40 schrieb 艾超:
> 
> > Hi
> > 
> >     thanks for your help.
> > 
> > > Is there a way to determine the current state of the camera switch
> > without having
> > > to wait for an WMI event?
> > 
> > There is no other way to detemine the current state of the camera
> > switch without
> > 
> > a WMI event.
> > 
> > 
> > > If its not possible to determine the current state of the camera
> > switch, then your
> > > driver has to defer the initialization of the input device until it
> > knows the current
> > > state of the camera switch. Otherwise the initial switch state
> > reported by the
> > > input device might be wrong.
> > 
> > > In this case, that means your driver must initialize the input
> > device when receiving
> > > a valid WMI event for the first time.
> > 
> > > Basically when your driver receives a WMI event, it has to check if
> > the input device
> > > is already initialized. If this is not the case, then the input
> > device is initialized.
> > > Please protect this check and the input device initialization with a
> > mutex, since WMI
> > > event handling is multithreaded.
> > 
> > 
> > This Camera is a UVC device, and the Carema device is already
> > initialized before the WMI
> > 
> > event .  Whether the camera switch is on or off, we can used lsusb to
> > check the Camera.

It depends on which drivers are built-in and which are modules. The fact
that on one distribution WMI happens to enumerate after PCI/USB is just
a stroke of luck.

> > 
> > This wmi-camera driver only need to report the current state of the
> > camera switch.
> > 
> > 
> > Thanks.
> > 
> >     Ai Chao
> > 
> I see, so userspace will notice when the camera is disabled. Since the camera disappears from
> the USB bus when the switch is activated, i wonder if SW_CAMERA_LENS_COVER is the right thing
> to use in this case after all.
> 
> I CCed the maintainer of the input subsystem so that he can maybe provide some advise.
> I for example would, taking the above information above the UVC device into account, say that
> KEY_CAMERA_ACCESS_ENABLE/KEY_CAMERA_ACCESS_DISABLE is more suitable. Then userspace has to
> keep track of the camera state (through lsusb for example).

KEY_CAMERA_ACCESS_ENABLE/KEY_CAMERA_ACCESS_DISABLE is supposed to affect
all cameras connected to the system (HUTRR72: "The proposal is to add a
set of new Usage IDs to the Consumer Page (0x0C) to control programmatic
access to *all* camera devices connected to a computer." - emphasis
mine).

SW_CAMERA_LENS_COVER is useful when camera is always present but may be
covered.

If I understand this correctly the camera disappears from the bus and
reappears again when enabled. In this case why do you need the key event
at all? Are you planning on having a "stub" for the camera so that
userspace believes that the camera is always present but may be not
operational?

Thanks.

-- 
Dmitry