linux-kernel - Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a subdevice

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: <20241110110257.5160a7d1@foz.lan>
Date: Sun, 10 Nov 2024 11:02:57 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Hans de Goede <hdegoede@...hat.com>, Laurent Pinchart
 <laurent.pinchart@...asonboard.com>, Mauro Carvalho Chehab
 <mchehab@...nel.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>,
 linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, Yunke Cao
 <yunkec@...omium.org>, Hans Verkuil <hverkuil@...all.nl>
Subject: Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a
 subdevice

Em Sat, 9 Nov 2024 17:29:54 +0100
Ricardo Ribalda <ribalda@...omium.org> escreveu:

> >
> > I think that should sort the issue, assuming that 1. above holds true.
> >
> > One downside is that this stops UVC button presses from working when
> > not streaming. But userspace will typically only open the /dev/video#
> > node if it plans to stream anyways so there should not be much of
> > a difference wrt button press behavior.  
> 
> I do not personally use the button, but it is currently implemented as
> a standard HID device. 

IMO, controlling the privacy via evdev is the best approach then. There's
no need for a RW control neither at subdev or at device level. It could
make sense a Read only to allow apps to read, but still it shall be up to
the Kernel to protect the stream if the button is pressed.

> Making it only work during streamon() might be
> a bit weird.
> I am afraid that if there is a button we should keep the current behaviour.

Privacy matters only when streaming. IMO the Kernel check for it needs to
be done at DQBUF time and at read() calls, as one can enable/disable the
camera while doing videoconf calls. I do that a lot with app "soft" buttons,
and on devices that physically support cutting the video. 

I don't trust myself privacy soft buttons, specially when handled in userspace,
so what I have are webcam covers (and a small stick glued at a laptop camera
that has a too small sensor for a webcam cover). I only remove the cover/stick
when I want to participate on videoconf with video enabled with the builtin
camera.

Regards

Thanks,
Mauro