From: Ricardo Ribalda <ribalda@chromium.org>
To: Michal Pecio <michal.pecio@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Hans de Goede <hansg@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH v3 3/4] media: uvcvideo: Introduce allow_privacy_override module parameter
Date: Thu, 19 Mar 2026 10:56:59 +0100 [thread overview]
Message-ID: <CANiDSCsBjgZL0MGFgkDzbTaJ03hE0gZbV3tu3fKo7k6KaAcMZw@mail.gmail.com> (raw)
In-Reply-To: <20260319013657.155efeb0.michal.pecio@gmail.com>
Hi Michal
On Thu, 19 Mar 2026 at 01:37, Michal Pecio <michal.pecio@gmail.com> wrote:
>
> On Mon, 16 Mar 2026 13:34:46 +0000, Ricardo Ribalda wrote:
> > Some camera modules have XU controls that can configure the behaviour of
> > the privacy LED.
> >
> > Block mapping of those controls, unless the module is configured with
> > a new parameter: allow_privacy_override.
> >
> > This is just an interim solution. Based on the users feedback, we will
> > either put the privacy controls behind a CONFIG option, or completely
> > block them.
>
> What feedback do you expect to get?
I want to identify the valid usecases for overriding the privacy LEDs.
>
> Users will one day see their setup broken.
> They will curse you and jump through the hoops you set up.
> Next year they will see their setup broken completely.
> They will curse again and wish you all pain, but *after* the fact.
The goal of the deprecation period is exactly this: to trigger a
conversation before a permanent block. If a user relies on this, they
can report it now. We can then decide if we need a specialized API for
their use case or a Kconfig option, rather than leaving the current
"anyone can turn off the privacy LED" status quo.
>
> > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > ---
> > drivers/media/usb/uvc/uvc_ctrl.c | 38 ++++++++++++++++++++++++++++++++++++++
> > drivers/media/usb/uvc/uvc_driver.c | 20 ++++++++++++++++++++
> > drivers/media/usb/uvc/uvc_v4l2.c | 7 +++++++
> > drivers/media/usb/uvc/uvcvideo.h | 2 ++
> > include/linux/usb/uvc.h | 4 ++++
> > 5 files changed, 71 insertions(+)
>
> This doesn't seem to cover libusb, VM guests and such.
For libusb and VM guests to work you need to unbind the uvc driver.
Only privileged users can do that.
Today, any user with camera access can disable the privacy LED.
>
> What's even the attack vector? It has to be full remote code execution.
> And it's just an LED, when you see it turn on somebody already has your
> mugshot, if you notice at all. And the mugshot isn't your worst worry.
The attack vector is that an app with camera access, like your
browser, can record you when you don't want to be recorded.
The LED will be a signal that something is happening.
Imagine that you install a Flatpak for live streaming. Assuming the
Flatpak is properly sandboxed, remote code execution is less worrisome
than the app spying on you.
>
> >
> > diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
> > index b6e020b41671..3ca108b83f1d 100644
> > --- a/drivers/media/usb/uvc/uvc_ctrl.c
> > +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> > @@ -3001,6 +3001,35 @@ static int uvc_ctrl_init_xu_ctrl(struct uvc_device *dev,
> > return ret;
> > }
> >
> > +bool uvc_ctrl_is_privacy_control(u8 entity[16], u8 selector)
> > +{
> > + /*
> > + * This list is not exhaustive, it is a best effort to block access to
> > + * non documented controls that can affect user's privacy.
> > + */
>
> So it's not removal of some controversial feature, but 3KB of extra
> code in everybody's kernel (I just applied this patch) and a forever
> game of whack-a-mole with HW vendors? They will win...
Maybe I meassured it wrong. But I can only account for 1.3 KiB
$ size drivers/media/usb/uvc/uvcvideo-without.ko
text data bss dec hex filename
115974 3748 88 119810 1d402 drivers/media/usb/uvc/uvcvideo.ko
$ size drivers/media/usb/uvc/uvcvideo-with.ko
text data bss dec hex filename
117315 3767 88 121170 1d952 drivers/media/usb/uvc/uvcvideo.ko
I see no need for vendors to hide these features, they simply added
them because an OEM thought it was a nice feature to have, or because
they left them as hardware debug features.
>
> You will blacklist features found by legitimate users and shared on
> public forums, while hackers will keep their findings to themselves.
> Assuming that there are any who even care.
If a legitimate user needs a feature, this patch gives them a way to
keep using it (allow_privacy_override) while notifying us. This allows
the community to find a better, safer way to support that specific
need without leaving the door wide open for everyone else.
>
> > + struct privacy_control {
> > + u8 entity[16];
> > + u8 selector;
> > + } privacy_control[] = {
> > + {
> > + .entity = UVC_GUID_LOGITECH_USER_HW_CONTROL_V1,
> > + .selector = 1,
> > + },
> > + {
> > + .entity = UVC_GUID_LOGITECH_PERIPHERAL,
> > + .selector = 9,
> > + },
> > + };
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(privacy_control); i++)
> > + if (!memcmp(entity, privacy_control[i].entity, 16) &&
> > + selector == privacy_control[i].selector)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
> > struct uvc_xu_control_query *xqry)
> > {
> > @@ -3045,6 +3074,15 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
> > return -ENOENT;
> > }
> >
> > + if (uvc_ctrl_is_privacy_control(entity->guid, xqry->selector) &&
> > + !uvc_allow_privacy_override_param) {
> > + dev_warn_once(&chain->dev->intf->dev,
> > + "Privacy related controls can only be accessed if module parameter allow_privacy_override is true\n");
> > + uvc_dbg(chain->dev, CONTROL, "Blocking access to privacy related Control %pUl/%u\n",
> > + entity->guid, xqry->selector);
> > + return -EACCES;
> > + }
> > +
> > if (mutex_lock_interruptible(&chain->ctrl_mutex))
> > return -ERESTARTSYS;
> >
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> > index b0ca81d924b6..74c9dea29d36 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -36,6 +36,7 @@ unsigned int uvc_no_drop_param = 1;
> > static unsigned int uvc_quirks_param = -1;
> > unsigned int uvc_dbg_param;
> > unsigned int uvc_timeout_param = UVC_CTRL_STREAMING_TIMEOUT;
> > +bool uvc_allow_privacy_override_param;
> >
> > static struct usb_driver uvc_driver;
> >
> > @@ -2505,6 +2506,25 @@ MODULE_PARM_DESC(trace, "Trace level bitmask");
> > module_param_named(timeout, uvc_timeout_param, uint, 0644);
> > MODULE_PARM_DESC(timeout, "Streaming control requests timeout");
> >
> > +static int param_set_privacy(const char *val, const struct kernel_param *kp)
> > +{
> > + pr_warn_once("uvcvideo: " DEPRECATED
> > + "allow_privacy_override parameter will be eventually removed.\n");
> > + return param_set_bool(val, kp);
> > +}
> > +
> > +static const struct kernel_param_ops param_ops_privacy = {
> > + .set = param_set_privacy,
> > + .get = param_get_bool,
> > +};
> > +
> > +param_check_bool(allow_privacy_override, &uvc_allow_privacy_override_param);
> > +module_param_cb(allow_privacy_override, ¶m_ops_privacy,
> > + &uvc_allow_privacy_override_param, 0644);
> > +__MODULE_PARM_TYPE(allow_privacy_override, "bool");
> > +MODULE_PARM_DESC(allow_privacy_override,
> > + "Allow access to privacy related controls");
> > +
> > /* ------------------------------------------------------------------------
> > * Driver initialization and cleanup
> > */
> > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
> > index f9049e9c0d3a..6d4f027c8402 100644
> > --- a/drivers/media/usb/uvc/uvc_v4l2.c
> > +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> > @@ -133,6 +133,13 @@ static int uvc_ioctl_xu_ctrl_map(struct uvc_video_chain *chain,
> > return -EINVAL;
> > }
> >
> > + if (uvc_ctrl_is_privacy_control(xmap->entity, xmap->selector) &&
> > + !uvc_allow_privacy_override_param) {
> > + dev_warn_once(&chain->dev->intf->dev,
> > + "Privacy related controls can only be mapped if module parameter allow_privacy_override is true\n");
> > + return -EACCES;
> > + }
> > +
> > map = kzalloc_obj(*map);
> > if (map == NULL)
> > return -ENOMEM;
> > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> > index 8480d65ecb85..362110d58ca3 100644
> > --- a/drivers/media/usb/uvc/uvcvideo.h
> > +++ b/drivers/media/usb/uvc/uvcvideo.h
> > @@ -664,6 +664,7 @@ extern unsigned int uvc_no_drop_param;
> > extern unsigned int uvc_dbg_param;
> > extern unsigned int uvc_timeout_param;
> > extern unsigned int uvc_hw_timestamps_param;
> > +extern bool uvc_allow_privacy_override_param;
> >
> > #define uvc_dbg(_dev, flag, fmt, ...) \
> > do { \
> > @@ -794,6 +795,7 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
> > struct uvc_xu_control_query *xqry);
> >
> > void uvc_ctrl_cleanup_fh(struct uvc_fh *handle);
> > +bool uvc_ctrl_is_privacy_control(u8 entity[16], u8 selector);
> >
> > /* Utility functions */
> > struct usb_host_endpoint *uvc_find_endpoint(struct usb_host_interface *alts,
> > diff --git a/include/linux/usb/uvc.h b/include/linux/usb/uvc.h
> > index dea23aabbad4..70c2a7d25236 100644
> > --- a/include/linux/usb/uvc.h
> > +++ b/include/linux/usb/uvc.h
> > @@ -49,6 +49,10 @@
> > #define UVC_GUID_LOGITECH_PERIPHERAL \
> > {0x21, 0x2d, 0xe5, 0xff, 0x30, 0x80, 0x2c, 0x4e, \
> > 0x82, 0xd9, 0xf5, 0x87, 0xd0, 0x05, 0x40, 0xbd }
> > +#define UVC_GUID_LOGITECH_USER_HW_CONTROL_V1 \
> > + {0x82, 0x06, 0x61, 0x63, 0x70, 0x50, 0xab, 0x49, \
> > + 0xb8, 0xcc, 0xb3, 0x85, 0x5e, 0x8d, 0x22, 0x1f }
> > +
> >
> > /* https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5#222-extension-unit-controls */
> > #define UVC_MSXU_CONTROL_FOCUS 0x01
> >
> > --
> > 2.53.0.851.ga537e3e6e9-goog
> >
--
Ricardo Ribalda
next prev parent reply other threads:[~2026-03-19 9:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 13:34 [PATCH v3 0/4] media: uvcvideo: Map known XU controls Ricardo Ribalda
2026-03-16 13:34 ` [PATCH v3 1/4] media: uvcvideo: Import standard controls from uvcdynctrl Ricardo Ribalda
2026-03-16 13:34 ` [PATCH v3 2/4] media: uvcvideo: Announce deprecation intentions for UVCIOC_CTRL_MAP Ricardo Ribalda
2026-03-16 13:34 ` [PATCH v3 3/4] media: uvcvideo: Introduce allow_privacy_override module parameter Ricardo Ribalda
2026-03-19 0:36 ` Michal Pecio
2026-03-19 9:56 ` Ricardo Ribalda [this message]
2026-03-19 11:08 ` Michal Pecio
2026-03-19 11:43 ` Ricardo Ribalda
2026-03-24 12:07 ` Michal Pecio
2026-03-26 11:55 ` Ricardo Ribalda
2026-03-16 13:34 ` [PATCH v3 4/4] media: uvcvideo: RFC: Convert allow_privacy_override into Kconfig Ricardo Ribalda
2026-03-18 14:16 ` Greg Kroah-Hartman
2026-03-18 14:57 ` Ricardo Ribalda
2026-03-19 11:50 ` Gergo Koteles
2026-03-19 12:06 ` Ricardo Ribalda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANiDSCsBjgZL0MGFgkDzbTaJ03hE0gZbV3tu3fKo7k6KaAcMZw@mail.gmail.com \
--to=ribalda@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=hansg@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=michal.pecio@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox