linux-kernel - Re: Function of the camera key on windows

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: <c2d0c706-e006-6c2f-8fe6-ea20a745ddd6@redhat.com>
Date:   Wed, 26 Apr 2023 10:59:33 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Jonathan Singer <jes965@....edu>,
        platform-driver-x86@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Function of the camera key on windows

Hi,

On 4/25/23 23:09, Jonathan Singer wrote:
> The key itself triggers a hardware response both on windows and linux.
> It disconnects power from the camera USB module and raises a cover in front
> of the camera aperature. The keycode is as far as I know only to notify the
> operating system in case it wanted to show a message.
> 
> Is that the kind of use case that would benefit from emitting a KEY_CAMERA?

Actually we have SW_CAMERA_LENS_COVER for this and this is what
new Dell laptops with a similar feature use.

The problem with using a SW for this though is that we should then either:

a) Figure out a way to identify models which will report this; or
b) register a separate input_dev just for reporting the SW
   on the first event.

This is necessary because unlike keys where only press + release
events really matter and if those never happens no harm is done,
switches can be acted upon by userspace in both there open and closed
state, so the mere presence of an input_device with a SW_CAMERA_LENS_COVER
may be acted upon by userspace. E.g. if we by default report
SW_CAMERA_LENS_COVER=1 (so lenscover closed) then apps who want to access
the camera may ask the user something like: "Your camera is currently
unavailable, please press the keyboard combination to enable your camera"
which makes no sense to ask on devices without such feature.

Note that simply registering a separate input_dev for just reporting
SW_CAMERA_LENS_COVER on the first event is a good workaround for
this though. We already do the same in other drivers for SW_TABLET_MODE
for similar reasons.

A second problem is that we would need to be able to tell if we
get the 0x1A event because of the camera being enabled or disabled,
but perhaps this info is already present in the event_data ?

Regards,

Hans