linux-kernel - Re: [PATCH] ACPI / button: Avoid using broken

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: <1456150475.23430.16.camel@hadess.net>
Date:	Mon, 22 Feb 2016 15:14:35 +0100
From:	Bastien Nocera <hadess@...ess.net>
To:	"Zheng, Lv" <lv.zheng@...el.com>,
	"Chen, Yu C" <yu.c.chen@...el.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"Zhang, Rui" <rui.zhang@...el.com>,
	"cwhuang@...roid-x86.org" <cwhuang@...roid-x86.org>
Subject: Re: [PATCH] ACPI / button: Avoid using broken _LID on Surface tablet

On Mon, 2016-02-22 at 07:24 +0000, Zheng, Lv wrote:
> [Lv Zheng] 
> According to the knowledge of various BIOS _LID implementation, Linux
> button driver doesn't seem to be working wrong.
> It in fact works correctly and is able to handle all BIOS _LID
> implementations.
> 
> So this looks to me like a user space bug.

I don't think it is one, given the kernel API for that functionality.
If, instead of exposing the lid as an input switch, the kernel only
ever sent an event saying "the lid is now closed" then we wouldn't have
that problem, as we'd likely expect the lid to be opened when starting
the machine (if present).

> That the user space doesn't contain a proper mode to handle ACPI BIOS
> _LID implementations.
> 
> Why should kernel work this gap around?
> The gap is:
> The user space requires lid device to act in the way it wants.

In the way that it's always worked up until now, rather.

> While the ACPI BIOS only provides lid behavior that is working for
> Windows power-saving settings.
> IMO,
> 1. Windows Only requires LID close notifications to trigger power-
> save action and only evaluates _LID after receiving a LID
> notification,
>     BIOSen only ensure _LID returning value is correct after a
> notification.

In which case, expecting the lid to always be opened on startup would
probably be a fair assumption, no?

> 2. But Linux user space requires all LID notifications to be
> instantly/correctly reported and wants to know the exact LID states
> whenever it reads the states from the sysfs.
> It doesn't seem to be possible for the kernel to work between BIOSen
> and the user space to fill such a gap.

If you quirk the kernel lid handling to always be opened on startup,
and we waited until the first event to correct it if necessary, seems
like the easiest way to go.

But that brings me the question of how Windows (and then Linux) behave
when you've booted your laptop and closed the lid straight away, before
any driver in the OS had the chance to be around to see the
notification?

It also brings the question of how Windows will know that the lid is
still closed when coming out of suspend by pressing the power button,
which can happen depending on the hardware design (it's certainly
possible to press the power button with the lid closed on the Surface
3, and likely other Surfaces).

I'm not happy about the "fix" for this problem either, but blaming
user-space for this is harsh, given the API exported by the kernel and
how pretty much every laptop worked.

Cheers