linux-kernel - Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after suspend to RAM.

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]

Date:	Thu, 27 Mar 2014 09:06:20 +1030
From:	Kieran Clancy <clancy.kieran@...il.com>
To:	Stefan Biereigel <stefan@...reigel.de>
Cc:	Juan Manuel Cabo <juanmanuel.cabo@...il.com>,
	Stefan Biereigel <security@...reigel-wb.de>,
	Lan Tianyu <lantianyu1986@...il.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r kernel org" <linux-kernel@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	San Zamoyski <san@...snet.pl>,
	"D. Jansen" <dennis.jansen@....de>,
	"Maurizio D'Addona" <mauritiusdadd@...il.com>
Subject: Re: [REGRESSION 3.14-rc6] Samsung N150 lid does not "open" after
 suspend to RAM.

On Thu, Mar 27, 2014 at 6:26 AM, Stefan Biereigel <stefan@...reigel.de> wrote:
> I tested both of your patches. The processing of events works well on my
> N150, the lid is reported open correctly after resume.
> For the second patch (the whitelisting-approach), I had to change the
> Product Name to "N150/N210/N220" instead of "N150P", because that is
> what dmidecode reports for my netbook.

That was quick - thanks for testing!

For the product name match then, it matches substrings not whole
strings, so "N150" should be sufficient (my mistake putting P on the
end).

> So, all three approaches work equally well for me (whitelisting my
> broken N150, blacklisting the broken Series 5/7/9, processing all the
> stale events). I personally would prefer a solution which needs to
> handle (best case) no custom cases, because there are always n+1 of
> them. But, as I don't know if there may be any problems with the
> approach that needs no special handling (processing all stale events) in
> the future, I'm not the one to decide the correct solution.

I won't be able to test ec_clear_process patch until tomorrow because
I have a full day today.

On my machine, _QXX events are all something like:

if (AC_PLUGGED_IN) {
    do_something();
}

So if (for example) AC_PLUGGED_IN has changed since the event was
produced (e.g. no longer plugged in), nothing bad should happen.
That's not necessarily a guarantee that this wouldn't introduce new
bugs on other machines though.

I think the ideal fix would be to distinguish between events which are
"jammed" and won't be processed (like on Series 5/7/9), and events
which will be processed normally with GPEs (N150). I am not sure how
to do this or if it's even possible.

For example, on my machine, the EC status byte (EC_SC) seems to be
0x29 for jammed events, which means the SCI_EVT bit is set but we
never got/get the interrupt. On your N150, your status byte was 0x09
which means the SCI_EVT was not set - it was not yet asking for the OS
to attend to this.

I wonder if something as simple as this would work (in acpi_ec_clear):

                if (!(acpi_ec_read_status(ec) & ACPI_EC_FLAG_SCI))
                        break;
                status = acpi_ec_query_unlocked(ec, &value);
                if (status || !value)
                        break;

This would make it only clear events while the SCI_EVT bit is set. I
am not sure that it would entirely remove the race condition you are
seeing, but it might be enough to fix it.

If we cant come up with a generally applicable solution, whitelisting
is the lesser of two evils when compared with blacklisting here. A
jammed EC won't function _at all_, while losing one or two EC events
on boot/resume doesn't prevent future events and is easier to work
around (though still not ideal).

Regards,
Kieran.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/