linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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]

Date:	Fri, 28 May 2010 16:24:57 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Fri, 28 May 2010 15:02:37 +0100
> Ok, I think I've misunderstood you. You're actually saying that only 
> applications that are trusted to behave well are allowed to receive 
> wakeup events? Yes, that makes implementation significantly easier. If 

To receive them in a manner that they are permitted to defer a suspend.
There is non reason why bouncing cows shouldn't get to see an event, but
there is always the miniscule possibility that we choose to suspend as it
gets the event.

That to me seems fine. Our starting basis was

- Bouncing cows is not trusted

Android's reaction was

- We reserve the right to suspend bouncing cows where it likes it or not

The caveat becomes

- Bouncing cows may get suspended then get an event when the phone wakes
  back up. So I might press "Moo" just before a suspend and get the noise
  when it resumes.

Given the untrusted cows could respond to the event otherwise by blocking
the suspend for as long as permitted with a suspend blocker or similar
that seems no worse. In this case probably better [oof zap! as opposed to
60 seconds of 'event, no sorry got a cow to draw at 100% CPU')

As the app is untrusted we can't assume they would get suspend blockers
right even if they had any.

You can still be nice to the cows app and when the phone is put down send
it a 10 second warning via dbus or Android equivalents.

Your trusted call handling app can still request (by QoS or big hammers)
that the phone does not suspend even if the app goes idle (because you
have a wakeup latency QoS)

A naïve trusted app will behave according to power management idling to
suspend and get stopped

A naïve untrusted app that is doing sane things will spend most of its
life asleep and behave.

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