linux-kernel - Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen

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: <CAJZ5v0h_8aA+VwBb5B1tKn5Y0Herb3dG=Qjy1uueA4V83FUcCg@mail.gmail.com>
Date: Thu, 4 Dec 2025 17:41:35 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Dmitry Osipenko <dmitry.osipenko@...labora.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Mario Limonciello <superm1@...nel.org>, 
	Robert Beckett <bob.beckett@...labora.com>, linux-acpi@...r.kernel.org, 
	kernel@...labora.com, linux-kernel@...r.kernel.org, 
	Sebastian Reichel <sebastian.reichel@...labora.com>, Xaver Hugl <xaver.hugl@...il.com>, 
	Richard Hughes <richard@...hsie.com>, William Jon McCann <mccann@....edu>, 
	"Jaap A . Haitsma" <jaap@...tsma.org>, Benjamin Canou <bookeldor@...il.com>, 
	Bastien Nocera <hadess@...ess.net>, systemd-devel@...ts.freedesktop.org, 
	Lennart Poettering <lennart@...ttering.net>, Antheas Kapenekakis <lkml@...heas.dev>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs interface

On Thu, Dec 4, 2025 at 4:04 PM Dmitry Osipenko
<dmitry.osipenko@...labora.com> wrote:
>
> On 12/3/25 17:58, Rafael J. Wysocki wrote:
> >> Add `/sys/power/lps0_screen_off` interface to allow userspace to control
> >> Display OFF/ON DSM notifications at runtime.
> > Why?
> >
> >> Writing "1" to this file triggers the OFF notification, and "0" triggers the ON notification.
> >>
> >> Userspace should write "1" after turning off all physical and remote
> >> displays. It should write "0" before turning on any of displays.
> > This sets a limitation on the correct/expected usage of this
> > interface.  How can the kernel ensure that the limitation is taken
> > into account?  In principle, it should not allow OFF to be triggered
> > if any displays are "on", for example.
> >
> > And what exactly do you mean by "turning off a display".  Cutting
> > power from it or something else?
>
> The common lowest level denominator for the "turned off display" should
> be that all display CRTCs are disabled and there are no active remote
> desktop sessions.
>
> For example, firmware of Intel laptops tracks state of a built-in
> display internally and treats display being tuned off when either
> display's CRTC is disabled or when backlight level is set to 0. This may
> be not the same for AMD firmware.
>
> Display On/Off notification is a hint to firmware that it's allowed to
> put machine into a lower power state where UI presented to a user may
> become non-interactive.

To be precise, that's what MSDN has to say about it:

"This _DSM Function will be invoked when the operating system has
entered a state where all displays—local and remote, if any—have been
turned off. This could occur based on some user action, e.g. a button
press or lid close event, or expiration of some display power down
timer."

The "Intel Low-power S0 Idle" specification
(https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf)
says almost the same thing.

None of them says what kind of hint this is to the firmware and what
the firmware is expected to do in response to it.

> In practice, entering this lower power state makes device to pretend
> that it has been suspended. On a laptop, keyboard backlight will be
> turned off and power button LED will start blinking. This allows us to
> implement the "resume to a dark mode", mentioned in the cover letter.

Maybe, depending on what the firmware actually does.

> It's up to userspace to make decision when and what DSM notification
> should be issued, thus the new sysfs control.

Why would it be up to user space?

> There is no strict requirement on having displays to be turned off when
> Display OFF notification is issued. Machine won't blow up when display
> is enabled and OFF notification is set. Hence, it should be unnecessary
> for kernel to be extra cautious RE trusting userspace.

That is until one of them actually blows up when that happens.

As it stands, I'm totally unconvinced.

I generally think that allowing user space to trigger evaluation of
AML via sysfs is risky, pretty much regardless of what the given AML
has been designed for.  Turning that into kernel ABI is asking for
trouble.

Now, AFAIK this particular _DSM interface has been designed to be part
of the "modern standby" (or equivalent) flows, not to be used
separately, so assuming that it will always work the way you think it
will when used separately is kind of walking on thin ice IMV.

And there is also a concern regarding all of the systems where this
firmware interface is not present or not supported that will not get
the "dark resume" experience associated with it.  If you want "dark
resume" to be a feature of Linux, it should not depend on whether or
not a particular firmware is there and actually works the way you
like.