Open rugk opened 8 years ago
I can't agree with this. If there is some sort of attack, I prefer shutdown to be as quick as possible. I would rather see some battery stats issue after reboot than giving attacker more opportunity to continue with attack. There could be e.g. some exploit found in graceful shutdown code in the future (yes, it is unlikely, but like I said I prefer shutdown to be as quick as possible).
than giving attacker more opportunity to continue with attack.
But they don't have any opportunity as nothing can be done to prevent the shutdown or to unlock the device when it is shutting down AFAIK.
I wonder if using reboot -p
has the potential of harming the phone. E.g. the file systems don't get unmounted properly (or are they)?, etc.
According to this page, reboot -p
command can be changed to am broadcast android.intent.action.ACTION_SHUTDOWN && sleep 5 && reboot -p
, notifying apps about the impending shutdown. But I'm not sure this is enough time and if the filesystems will be unmounted?
At least it is a try, is not it?
I've checked logcat and am broadcast android.intent.action.ACTION_SHUTDOWN
alone does warn apps about the shutdown, but doesn't actually shutdown (hence the && sleep 5 && reboot -p
).
To do a regular reboot (same as if reboot is done from the Power button menu), the command is am start -a android.intent.action.REBOOT
. I really wonder what is the -a
option since it's not mentioned in the am's docs or it's built-in help. But reboot doesn't work without -a
.
I've found some info on the safety of reboot -p
with regards to the filesystems.
Both AOSP and Cyanogenmod do sync
and emergency remount read-only (using the same mechanism as the magic SysRq-U) all the filesystems.
See comments before the remount_ro
function. Here's the rationale behind this:
https://android.googlesource.com/platform/system/core/+/e3aeeb4de34dbb93e832e6554f494122ba633f3b
It looks to me like it would be quite safe to give apps a few seconds (is 5 enough?) to save their data, then just reboot -p
.
I think it's more reliable than a regular reboot (using am start
), which, if added, should be an option.
@gene-pavlovsky thanks for all the interesting research, you did!
so what shutdown-procedure do you suggest to use? special android-commands? with sync before or not, and which command for actual shutdown? i use Wrong PIN Shutdown where the command can be modified, so i'm very interested in this. maybe have a look at the similar discussion there.
@xmikos may i suggest to simply give the possibility to change the command (maybe with corresponding warning, readme, links to recourses) by advanced users like Wrong PIN Shutdown does.
In the end I started using Automagic for various things, and the functionality of SnooperStopper is easily replicated as an Automagic flow. I'm just using "Reboot" Automagic action (requires root).
well... i want to neither use non-FOSS software, nor have playstore installed! - so this is not an option for me.
if i understand this right, you are now using a predefined reboot-function of a proprietary app, where you don't even have an idea which command(s) are used...? :confused:
I see and respect your point. Wish I was that strong principled on this. Yes you understand me right. If I was writing a reboot script myself (which is also an option with Automagic, just I'm lazy), I would do something like:
am broadcast android.intent.action.ACTION_SHUTDOWN
sleep 5
reboot -p
You might want to increase the sleep duration, personally I wouldn't worry too much about this stuff, considering my phone spuriously reboots all by itself for unknown reasons once a month or so, and I didn't notice any harm done or loss of data in my apps :)
Instead of - somekind of - "unplug" the device from battery could you just do a graceful/normal shutdown?
Otherwise it not only looks like a system crash it also seems to cause issues like this: https://github.com/xmikos/SnooperStopper/issues/12
And I see no reasons for such a drastic shutdown method. During shutdown an attacker cannot unlock the device anyway...