linux-kernel - Re: Attempted summary of suspend-blockers LKML thread, take two

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: <AANLkTi=wyD-K35vQdhTr7kt4wHeEDkbvzkXHAOyMtzZJ@mail.gmail.com>
Date:	Thu, 5 Aug 2010 06:37:15 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	david@...g.hm
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk,
	menage@...gle.com, david-b@...bell.net, James.Bottomley@...e.de,
	tytso@....edu, arjan@...radead.org, swmike@....pp.se,
	galibert@...ox.com, dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take two

On Thu, Aug 5, 2010 at 6:18 AM,  <david@...g.hm> wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>
>> Continuing to rush in where angels fear to tread...
>
> here here :-)
>
>> o       "PM-driving application" are applications that are permitted
>>        to acquire suspend blockers on Android.  Verion 8 of the
>>        suspend-blocker patch seems to use group permissions to determine
>>        which applications are classified as power aware.  More generally,
>>        PM-driving applications seem to be those that have permission
>>        to exert some control over the system's sleep state.
>>
>>        Note that an application might be power-oblivious on one Android
>>        device and PM-driving on another, depending on whether the user
>>        allows that application to acquire suspend blockers.  The
>>        classification might even change over time.  For example, a
>>        user might give an application PM-driving status initially,
>>        but change his or her mind after some experience with that
>>        application.
>
> One thing that I think it's important to document here is theinformation
> that Brian provided in response to your question about how many (or actually
> how few) applications fall into this catefory

I think I need to clarify here.  When I say "app" in the context of
Android, I mean "an application running under the Android app model --
sandboxed under a per-app or app-group uid", not "a process".  The
vast majority of processes on an Android device are "apps" in this
sense, but some (usually low level services or daemons) are not.  Also
I use "wakelock" as a place holder for "suspend blocker" or whatever
exact API we're trying to hash out here, because it's shorter and I'm
lazy.

Any app may obtain a wakelock through the standard Android APIs,
provided it has permission to do so.  In the current implementation,
apps obtain wakelocks via making a binder RPC call to the power
manager service which tracks high level wakelocks (for apps!) and
backs them by a single kernel wakelock.  Access control is at the RPC
level.  This implementation could be changed to have the app API
simply open /dev/suspendblock or whatnot, with access control enforced
by unix permissions (the framework would arrange for apps with the
android "can block sleep" permission to be in a unix group that has
access to the device).

For native services (native daemons that run "underneath" the android
app framework -- for example the media service, the radio interface,
etc), the kernel interface is used directly (ok, usually via a very
thin C convenience wrapper).

Brian


> Quote:
>
>> I should have asked this earlier...  What exactly are the apps'
>> compatibility constraints?  Source-level APIs?  Byte-code class-library
>> invocations?  C/C++ dynamic linking?  C/C++ static linking (in other
>> words, syscall)?
>
> For Java/Dalvik apps, the wakelock API is pertty high level -- it
> talks to a service via RPC (Binder) that actually interacts with the
> kernel.  Changing the basic kernel<->userspace interface (within
> reason) is not unthinkable.  For example, Arve's suspend_blocker patch
> provides a device interface rather than the proc interface the older
> wakelock patches use.  We'd have to make some userspace changes to
> support that but they're pretty low level and minor.
>
> In the current model, only a few processes need to specifically
> interact with the kernel (the power management service in the
> system_server, possibly the media_server and the radio interface
> glue).  A model where every process needs to have a bunch of
> instrumentation is not very desirable from our point of view.  We
> definitely do need reasonable statistics in order to enable debugging
> and to enable reporting to endusers (through the Battery Usage UI)
> what's keeping the device awake.
>
> Brian
>
>
--
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/