linux-kernel - Re: suspend blockers & Android integration

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:	Sun, 6 Jun 2010 15:55:38 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, tytso@....edu,
	Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: suspend blockers & Android integration

On Sunday 06 June 2010, Arve Hjønnevåg wrote:
> 2010/6/5 Rafael J. Wysocki <rjw@...k.pl>:
> > On Saturday 05 June 2010, Arve Hjønnevåg wrote:
> >> 2010/6/5 Thomas Gleixner <tglx@...utronix.de>:
> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
...
> >
> > Arve, we're still learning you have some more requirements we had no idea
> 
> What new requirement are you talking about. Did you assume all our
> user-space ipc calls went though a single process?

No, but I didn't assume that your wakelock-holding processes depend on the
other processes in a way that might prevent them from acquiring or dropping
a wakelock.

...
> >> >> Trusted code that calls into untrusted code has to deal with the
> >> >> untrusted code not responding, but we only want to pop up a message
> >> >> that the application is not responding if it is misbehaving, not just
> >> >> because it was frozen though no fault of its own.
> >
> > When Android starts opportunistic suspend, all applications are frozen,
> > "trusted" as well as "untrusted", right?  So, after they are all frozen, none
> > of them can do anything to prevent suspend from happening, right?
> 
> Not if you mean when we write to /sys/power/state. Processes are not
> frozen until the last suspend blocker is released.

That doesn't matter.  In the opportunistic mode you don't need to write into
/sys/power/state to start suspend, this is done by the kernel automatically as
soon as the last wakelock has been released (at least this is my assumption
about how this works).  Now, at this point the processes that don't use
wakelocks can't really prevent themselves from being frozen and only the
wakelocks users can do that.  So, if a wakelock user depends on a process
that doesn't use wakelocks in such a way that (because of that dependence) it
can't acquire its wakelock while processes are being frozen, things don't work
as they are supposed to.

> > Now, in my proposed approach the "untrusted" apps are frozen exactly at the
> > point Android would start opportunistic suspend and they wouldn't be able
> > to do anything about that anyway.  So if one of your "trusted" apps depends
> > on the "untrusted" ones in a way that you describe, you alread have a bug
> > (the "trusted" app cannot prevent automatic suspend from happening even if it
> > wants, because it depends on an "untrusted" app that has just been frozen).
> >
> 
> I don't think what you said here is correct. If a wakeup event happens
> all processed are unfrozen since the driver blocks suspend.

This only means that the theoretical failure you gave as an example doesn't
happen in practice.  No problem, then. :-)

> The app that reads this event blocks suspend before reading it. If it was
> busy talking to a less trusted app when the event happened it still works
> since all apps are running at this point.

And how is this different from an approach with cgroup freezing?  Apps that
use wakelock within the current framework would use "freeze locks" to prevent
the "untrusted" part of user space from being frozen or to thaw it.  Where's
the problem, then?

Rafael
--
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/