linux-kernel - RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

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: <1AE640813FDE7649BE1B193DEA596E883BBA30A5@SHSMSX101.ccr.corp.intel.com>
Date:	Thu, 19 May 2016 01:59:21 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	Bastien Nocera <hadess@...ess.net>,
	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"Brown, Len" <len.brown@...el.com>
CC:	Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: RE: [RFC PATCH 1/2] ACPI / button: Send "open" state after
 boot/resume

Hi,

> From: Bastien Nocera [mailto:hadess@...ess.net]
> Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after
> boot/resume
> 
> On Tue, 2016-05-17 at 16:27 +0800, Lv Zheng wrote:
> > (This patch hasn't been tested, it's sent for comments)
> >
> > Linux userspace (systemd-logind) keeps on rechecking lid state when the
> > lid state is closed. If it failed to update the lid state to open after
> > boot/resume, it could suspend the system. But as:
> > 1. Traditional ACPI platform may not generate the lid open event after
> >    resuming as the open event is actually handled by the BIOS and the system
> >    is then resumed from a FACS vector.
> > 2. The _LID control method's initial returning value is not reliable. The
> >    _LID control method is described to return the "current" lid state,
> >    however the word of "current" has ambiguity, many BIOSen return lid
> >    state upon last lid notification while the developers may think the
> >    BIOSen should always return the lid state upon last _LID evaluation.
> >    There won't be difference when we evaluate _LID during the runtime, the
> >    problem is the initial returning value of this function. When the BIOSen
> >    implement this control method with cached value, the initial returning
> >    value is likely not reliable.
> > Thus there is no mean for the ACPI lid driver to provide such an event
> > conveying correct current lid state. When there is no such an event or the
> > event conveys wrong result, false suspending can be examined.
> >
> > The root cause of the issue is systemd itself, it could handle the ACPI
> > control method lid device by implementing a special option like
> > LidSwitchLevelTriggered=False when it detected the ACPI lid device. However
> > there is no explicit documentation clarified the ambiguity, we need to
> > work it around in the kernel before systemd changing its mind.
> >
> > Link 1: https://lkml.org/2016/3/7/460
> > Link 2: https://github.com/systemd/systemd/issues/2087
> > Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=89211
> >         https://bugzilla.kernel.org/show_bug.cgi?id=106151
> >         https://bugzilla.kernel.org/show_bug.cgi?id=106941
> > Signed-off-by: Lv Zheng <lv.zheng@...el.com>
> > Cc: Bastien Nocera: <hadess@...ess.net>
> 
> As mentioned previously, I'd be much happier if either:
> - a new system was put in place that matched the ACPI specs and the way
> they are used by Windows
[Lv Zheng] 
Then what about the old systems?
Surface Pro 1 and Surface 3 are MS platforms that should have already adapted to the Windows.
They are currently suffering from the same issue by running Linux.

> - an additional tag/property was added to show that the API offered by
> the LID switch is different from the one that existing since ACPI
> support was added to Linux.
> 
> And I'd really appreciate it if you stopped saying that it's systemd's
> fault.
[Lv Zheng] 
OK.
Instead of saying this is a fault, I'll say systemd may need an additional option to handle ACPI lid device.

> 
> The kernel has offered an API to user-space that included the state of
> the LID switch. And the state of the LID switch has been correct for
> the majority of systems and devices for the past decade or so. The fact
> that this device means that the LID state isn't reliable anymore means
> that the kernel needs to communicate that to user-space.
> 
> I'm volunteering to modify systemd and UPower to respect the fact that
> the LID switch state isn't available on those devices. If you want to
> find something to blame, blame the kernel for implementing an API that
> doesn't reflect what the hardware makes available. Though you can only
> say that with the benefit of hindsight.
> 
> So, NAK from me.
[Lv Zheng] 
I'm out of the context here.
This patch is generated to respect the current systemd behavior.
If not, we'd rather just delete the 2 wrong lines.
I know that you need a documentation clarification, we are putting effort on this.

Thanks and best regards
-Lv