linux-kernel - Re: [PATCH v5 3/4] leds: led-class: Add devicetree support to led

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: <jsLJqyPfjA2iFNHMvAxgz-zO1WecVgleSahWgW_B5BshbYat4X1UqUuKpexfxlRxnD3oWlAnHqeLGpne8JebFV-ICVxvr5g-5nI8P2Q6dY8=@vinarskis.com>
Date: Wed, 10 Sep 2025 12:54:08 +0000
From: Aleksandrs Vinarskis <alex@...arskis.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Hans de Goede <hansg@...nel.org>, Lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Bryan O'Donoghue <bryan.odonoghue@...aro.org>, Jingoo Han <jingoohan1@...il.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Jean-Jacques Hiblot <jjhiblot@...phandler.com>, Jacopo Mondi <jacopo@...ndi.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>, Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, Daniel Thompson <danielt@...nel.org>, linux-leds@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org, linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org, threeway@...il.com, Andy Shevchenko <andy.shevchenko@...il.com>, Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v5 3/4] leds: led-class: Add devicetree support to led_get()






On Wednesday, September 10th, 2025 at 14:22, Konrad Dybcio <konrad.dybcio@....qualcomm.com> wrote:

>
>
> On 9/10/25 2:01 PM, Aleksandrs Vinarskis wrote:
>
> > From: Hans de Goede hansg@...nel.org
> >
> > Add 'name' argument to of_led_get() such that it can lookup LEDs in
> > devicetree by either name or index.
> >
> > And use this modified function to add devicetree support to the generic
> > (non devicetree specific) [devm_]led_get() function.
> >
> > This uses the standard devicetree pattern of adding a -names string array
> > to map names to the indexes for an array of resources.
> >
> > Reviewed-by: Andy Shevchenko andy.shevchenko@...il.com
> > Reviewed-by: Lee Jones lee@...nel.org
> > Reviewed-by: Linus Walleij linus.walleij@...aro.org
> > Signed-off-by: Hans de Goede hansg@...nel.org
> > Signed-off-by: Aleksandrs Vinarskis alex@...arskis.com
> > ---
>
>
> I was thinking, perhaps we should introduce some sort of an exclusive
> access mechanism, so that the e.g. user (or malware) can't listen to
> uevents and immediately shut down the LED over sysfs

It is already done by the original series from Hans (linked in cover),
which was merged few years back. It is also the reason why this
approach is used instead of typically used trigger-source - that
would've indeed allowed anyone with access to sysfs to disable the
indicator.

As per Hans [1], v4l2-core would disable sysfs of privacy indicator:

    sd->privacy_led = led_get(sd->dev, "privacy-led")
    led_sysfs_disable(sd->privacy_led);


Of course, this security only holds if one has secure boot enforced,
kernel, modules, _and_ device-tree blobs are signed.

Regards,
Alex

[1] https://lore.kernel.org/all/daf442a6-b4d6-4213-8ec0-10397d682cc4@kernel.org/

>
> Konrad