Avoid all user interaction during boot of a touch device

We want as little if any interaction possible/desirable at phone boot time.
Some fsck is inevitable due to read/write mounted user-data partition.
Mitigation by forcing mountall to answer yes to fsck.
On readonly system partitions we do not want to fsck at all (unlike developer mode where we likely want to at least have fsck -y by default).
Full-disk encryption will require plymouth interaction (presumably easier with a system compositor).

 * It was questioned on IRC if full disk encrypt is applicable for phones; userdata partition might be useful; convergence story still justifies talking about it, but maybe the screen keyboard etc. on phone is not a problem
  * interaction for recovery might be needed; adb might be an option
 * check with Steve Langasek who has made arguments in favour of this

[achiang]
We have been talking with some ISVs about security solutions on the phone. While encryption is mentioned, it is rarely specified whether we are talking about whole disk vs. userdata only. My sense is that we *probably* don't need whole disk on the phone.

UPDATE: talked with our lead here, and he indicates that he does not currently see a market need for whole-disk encryption. No one has been asking for this, including our security-minded customers.

Finally we did some research on what android does:

"I also enabled Android encryption on a Galaxy Nexus running our ROM and
booted it up to the initial unlock screen to do some poking around. At
that stage the only thing you can do on the phone without the
PIN/password is make an emergency call. /data is mounted as a tmpfs and
only contains the support files to run basic functions such as the UI
and the phone's radios. /data/* subdirectories on the disk, such as /data/ubuntu
are not available, even with a root shell.

Once you input the PIN or password the phone decrypts the /data/
partition and mounts it as a block device. At that point all of the
files you would expect are present and you can start Ubuntu normally."

[vorlon] Regardless of what ISVs are currently asking for and what Android implements, our plan for providing phone encryption should absolutely be vetted by the security team. The Android implementation has a serious vulnerability to an evil maid attack; my own phone is sufficiently easy to replace the OS on that I am now absolutely paranoid about keeping control of it, and data-only encryption doesn't protect you if the OS itself can be MITMed. Full-disk encryption may not actually be the thing to provide the necessary security, but it should be evaluated.

[bryanquigley]
Relevant performance benchmarks for home vs full disk (may be updated in a month with 3.10 results): http://www.phoronix.com/scan.php?page=article&item=ubuntu_1304_encryption&num=1
And of course this might need to be redone on an actual target phablet device for better results.

Links:
 * https://wiki.ubuntu.com/Plymouth
 * http://www.freedesktop.org/wiki/Software/kmscon

Idea: Maybe add this functionality to kmscon (https://github.com/dvdhrm/kmscon), and then have kmscon paint the startup screen?

Work items:
check with MIR team whether early input/output will be possible: TODO
look into kmscon to see whether it can act as a plymouth output renderer: TODO
figure out how to create an fstab at build time that refers to Android names where needed, so that it can have pass set to 0: TODO
ensure that behaviour is sensible when a filesystem (user-data) is sufficiently broken that it cannot even be mounted read-only; e.g. reboot directly into recovery: TODO
sort out the fact that running plymouth currently crashes the kernel, at least on the Nexus 7: TODO
[achiang] Find out if whole disk encryption is required in some commercial settings: DONE