[guardian-dev] developer sneak peak: CacheWord

Abel Luck abel at guardianproject.info
Sat Mar 30 13:11:36 EDT 2013


Mark Murphy:
> On Tue, Mar 26, 2013 at 2:10 PM, Hans-Christoph Steiner
> <hans at guardianproject.info> wrote:
>> Does Abel's AlarmManager method guarantee that the zeroing will be run?
> 
> No, as AlarmManager does not somehow magically prevent Android from
> terminating a process. Android could terminate the process in between
> alarms. In fact, that's pretty much the primary point behind
> AlarmManager.
> 

This is correct. My "AlarmManager method" works when the service is
foregrounded only. Thanks to Mark for making me aware of the fact that a
process could be killed by Android and then restarted by the AlarmManager.

>> It
>> seems from Java, there is no way to guarantee something will be run before its
>> killed without a permanent notification.  I guess that's something we can live
>> with, but otherwise, I think its annoying to have a permanent notification if
>> its not really communicating something essential.
> 
> A permanent notification is not the problem, IMHO. Saying that the
> process should live indefinitely is.
> 
>> But my guess is that if Android kills a process without even calling
>> onDestroy(), then its probably sending SIGKILL, and then native code won't
>> help.
> 
> That's certainly a valid guess, and would not surprise me in the
> least, but I would not leap to that conclusion. There are many, many
> layers between UNIX signals and component callbacks.
> 
>>  In that case, sounds like the permanent notification is required to
>> guarantee that the zeroification will be run.
> 
> Not even that will guarantee that the zeroification will be run. Force
> Stop, notably, should terminate a process, even one with foreground
> priority. Having a foreground service (with the "permanent
> notification") greatly increases the odds that zeroification will be
> run, but at a substantial cost:
> 
> - Everything that app does runs at foreground CPU priority, so if the
> app has a theoretically-background service doing stuff, that will
> impact the performance of the true foreground app, increasing the odds
> that the user will Force Stop the app just to get it to go away and
> stop messing up their game/video/whatever
> 
> - That app's memory cannot be reclaimed while it has foreground
> priority, putting pressure on the OS to get rid of other processes
> first, at minimum impacting device usability, and (if lots of apps
> were to adopt CacheWord or its equivalent) eventually causing severe
> system issues if several such apps are running
> 
> IMHO, particularly if catching a UNIX signal at the NDK level proves
> not to work, the foreground service has to be made optional and not be
> the default. I have no doubt that some percentage of apps that need to
> "generate, store, and access secrets derived from a user's passphrase"
> will need "guaranteed" zeroification, but certainly not all. Remember
> that *developers* may understand what they are gaining from this
> guarantee, but it is unlikely that the *user* will in many cases, and
> the *user* is the one that has to put up with the costs. Ideally, this
> is the sort of thing that a developer surfaces via a SharedPreference,
> so the user controls whether the foreground service is to be employed
> or not.
> 

Thanks for the clarification Mark.

This is what I had in mind from the first inception of CacheWord.
Currently the FG process is default, because I've been testing the more
"hardcore" use case because that's where all the features are used.

I agree that most apps do not need the aggressive footprint zeroization
demands, so I will make the service non-FG by default and allow the
developer to choose for himself whether to be more aggressive or not (or
allow the user to make the decision).

I'm still interested in how Android terminates processes and whether we
can do some signal catching in nativeland.

~abel


More information about the Guardian-dev mailing list