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: <CANiDSCt=Qht8CwAxCkpn=5owtQ_JBUkK+9yaLsZ5W2RJJxbz8A@mail.gmail.com>
Date: Sun, 10 Nov 2024 11:37:46 +0100
From: Ricardo Ribalda <ribalda@...omium.org>
To: Hans Verkuil <hverkuil@...all.nl>
Cc: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>, 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>
Subject: Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a subdevice

On Sun, 10 Nov 2024 at 11:29, Hans Verkuil <hverkuil@...all.nl> wrote:
>
> On 10/11/2024 11:02, Mauro Carvalho Chehab wrote:
> > 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.
>
> We could add a vb2_s_privacy(bool privacy) function to vb2 to tell vb2 if the privacy
> mode is on. And if so, take action. E.g. calling QBUF/DQBUF would return a -EACCES error.
>
> That will ensure consistent behavior for all drivers that have a privacy function.

I am not against adding a feature like this, but we still need a way
to notify userspace about a change of the privacy state when the user
presses it.
Controls are great for this.

>
> Note that there are two types of privacy GPIO: one that triggers when a physical
> cover is moved, blocking the sensor, and one that is a button relying on software
> to stop streaming video. In the first case it is informative, but you can keep
> streaming.

I am curious who implements a software privacy switch. I would
definitely use a physical cover in those devices.

Chromebooks only support physical cover and hardware privacy switch. I
have not seen software privacy switches.

>
> Regards,
>
>         Hans
>
> >
> > 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
> >
>


-- 
Ricardo Ribalda