ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 09/09/2013 01:09 AM, Alberto Mardegan wrote:
> On 09/05/2013 08:09 PM, Jamie Strandboge wrote:
>> On 09/05/2013 07:01 AM, Alberto Mardegan wrote:
>>> Well, if we don't have a myAppIsRunning() API, apps can simply
>>> busy-loop whenever they want, so I don't see much harm in adding
>>> this API. We could also protect it with apparmor, so that the
>>> usage of this API must be explicitly declared in the
>>> application's manifest file (and then we could question whether
>>> the app has any reason to use it).
>>>
>> We can't control access to library calls in this manner. You can
>> mmap the library and get everything, or you can't. We can't block
>> the mmap of the library because an app could just ship its own
>> version of the library and mmap it.
> [...]
> 
> Right. Then what about this approach:
> 
> ubuntu_api_start_busy_work():
>   - create an empty file in the app's namespace (maybe
>     $XDG_RUNTIME_DIR/<appId>/busy_work). This will fail if the app is
>     confined and not allowed to do busy work at all.
>   - setup a signal handler for the SIGXCPU signal.
> 
> ubuntu_api_stop_busy_work():
>   - removes the signal handler.
> 
> Then, when the watchgod service sees that an app is using "too much"
> CPU time, it would:
>   - check if $XDG_RUNTIME_DIR/<appId>/busy_work is present; if not,
>     kill the app
>   - send SIGXCPU
> 

This idea could be controlled via an apparmor policy group with a small tweak if
people actually wanted to do that. The app already has access to an application
specific directory in $XDG_RUNTIME_DIR and so we wouldn't want to use that
because then we would need an apparmor deny rule for the normal case, and
apparmor deny rules are evaluated last and take precedence. Long story short,
instead of using $XDG_RUNTIME_DIR/<appId>/busy_work, we use something like
$XDG_RUNTIME_DIR/ubuntu-api/<appId>/busy_work instead. Then we have a
'busy_work' policy group that allows rw access to
$XDG_RUNTIME_DIR/ubuntu-api/<appId>/busy_work. This would also allow other
things to be dropped in $XDG_RUNTIME_DIR/ubuntu-api/<appId>/ and controlled via
apparmor as needed.

>> I think the point of this API is not to protect against abuse, but
>> to allow a well-intentioned app from getting killed. To me, an
>> abusive app will be handled by bad reviews/bug reports ("This app
>> sucks-- my battery is dead in 5 minutes whenever I use it").
>> Because we don't have a way to distinguish between accidental and
>> intentional high CPU usage now, we don't have anything other than 
>> app reviews. If we introduce this call, we can detect the
>> accidental high CPU usage now. The handful of apps that abuse it
>> can still be handled via user reviews like they are now.
> 
> I agree, but having the application declare that it can be doing busy
> work for some seconds in its manifest file can be of great help for
> reviewers: if the capability is not mentioned in the manifest, it
> means that the application doesn't need a lot of investigation
> (because the app will automatically be killed if it misuses CPU).
> Also, if users report problems about a shortened battery life, we
> would first investigate those app which have the capability in their
> manifest.
> 
Perhaps. I'm still not convinced it should be controlled with apparmor, but I
don't have a strong opinion. Adding the policy group is easy and we can just
mark it as 'common' which will not block automation in our app reviews if people
wanted to pursue this route.


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature