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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0g2g9nDm+xOYpHQ6=NX40bem5atoSYhM46hjf+X_p+Ouw@mail.gmail.com>
Date:	Thu, 19 May 2016 15:21:33 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	"Zheng, Lv" <lv.zheng@...el.com>
Cc:	"Rafael J. Wysocki" <rafael@...nel.org>,
	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"Brown, Len" <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"Bastien Nocera:" <hadess@...ess.net>
Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

On Thu, May 19, 2016 at 3:50 AM, Zheng, Lv <lv.zheng@...el.com> wrote:
> Hi,
>
>> From: rjwysocki@...il.com [mailto:rjwysocki@...il.com] On Behalf Of
>> Rafael J. Wysocki
>> Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after
>> boot/resume

[cut]

>> > That's because of systemd implementation.
>> > It contains code logic that:
>> > When the lid state is closed, a re-checking mechanism is installed.
>> > So if we do not send any notification after boot/resume and the old lid state
>> is "closed".
>> > systemd determines to suspend in the re-checking mechanism.
>>
>> If that really is the case, it is plain silly and I don't think we can
>> do anything in the kernel to help here.
>
> [Lv Zheng]
> The problem is:
> If we just removed the 2 lines sending wrong lid state after boot/resume.
> Problem couldn't be solved.
> It could only be solved by changing both the systemd and the kernel (deleting the 2 lines).

There are two things here, there's a kernel issue (sending the fake
input events) and there's a user-visible problem.  Yes, it may not be
possible to fix the user-visible problem by fixing the kernel issue
alone, but pretty much by definition we can only fix the kernel issue
in the kernel.

However, it looks like it may not be possible to fix the user-visible
problem without fixing the kernel issue in the first place, so maybe
we should do that and attach the additional user space patch to the
bug entries in question?

[cut]

>> > I intentionally kept the _LID evaluation right after boot/resume.
>> > Because I validated Windows behavior.
>> > It seems Windows evaluates _LID right after boot.
>> > So I kept _LID evaluated right after boot to prevent compliance issues.
>>
>> I don't quite see what compliance issues could result from skipping
>> the _LID evaluation after boot.
>
> [Lv Zheng]
> I'm not sure if there is a platform putting named object initialization code in _LID.
> If you don't like it, we can stop evaluating _LID in the next version.

Well, unless there is a well-documented reason for doing this, I'd at
least try to see what happens if we don't.

Doing things for unspecified reasons is not a very good idea overall IMO.

[cut]

>> > [Lv Zheng]
>> > If we did this right now, many other userspace could be broken.
>> > So we prepared the options to allow users to choose.
>>
>> Do we have any evidence that any other user space stacks are affected?
>
> [Lv Zheng]
> I didn't know any of such affections except the systemd.

So let's focus on this one until we actually find another example.