Sofistes.net

Thursday, 30 August 2018

This blog deals with Android Marshmallow, things might have changed since then, especially as newer version support FBE (File-Based Encryption). M and older only supported FDE (Full-Disk Encryption) and the way it works is far from obvious but can be explained relatively concisely. I'll try to explain the flow below without getting stuck into too much detail.

Partition mounting starts in system/core/init/builtins.cpp, function do_mount_all(). This calls function fs_mgr_mount_all() and takes note of the return value. fs_mgr_mount_all() tries to mount each partition. If it fails, then the function checks if "encrypted" option is set for that partition in the fstab file. In this case it returns FS_MGR_MNTALL_DEV_MIGHT_BE_ENCRYPTED.

If do_mount_all() receives this return value, it will set three properties:

So at this point the system has seen there exist an encrypted device but does not know whether it has already been encrypted or not because this could be the very first boot.

trigger_default_encryption causes cryptfs_mount_default_encrypted() to be run. I.e. it starts the process of running the default encryption which is run the first time (with the default password). This function will check the type of password and if it has a valid value which is not CRYPT_TYPE_DEFAULT (i.e. user has changed it) it sets an important property:

vold.decrypt = trigger_restart_min_framework.

This starts the minimum framework which mounts the encrypted partition (/data in practice) to a temporary RAM disk and starts Zygote which then prompts the encryption password from the user. After user supplies the correct password, vold.decrypt is set to trigger_restart_framework, partition is decrypted and mounted (to /data) and Zygote is restarted. If the device wasn't encrypted (/data did not have the encrypted option) then init skips straight to this part.

This is, IMO, a pretty ugly solution and probably the easiest one for Google to handle encryption. It involves starting the almost the entire framework just to open a very simple view for the user to enter the password.

Monday, 15 January 2018

Building Android from the scratch is slow. In my work machine building Oreo takes about three hours. This is ok, if you don't need to do it too often but sometimes you have to run a full build for one reason or other. Often because something got corrupted and partial build won't finish.

A nice way to improve this would be to create a golden image which has a full build and make a copy of that when you want to do some work. If this new area gets corrupted, just make a new copy. The problem with this approach is it takes a lot of disk space. Just one workspace is almost 200 gigabytes and since SSD is the preferred disk type since it's much quicker to build using one of them it gets quite expensive if you need to support several variants. I have a terabyte of space for this on my work machine but I have potentially four different products to support.

Btrfs is an almost perfect solution: by using snapshots space requirements are much smaller. Btrfs only makes a new copy if a file is changed and since most files are unaltered the savings are huge.

Following is for my work machine which has two 500 gigabyte SSDs for this. Data is striped while metadata is mirrored.

Now when we want to code something, we create a snapshot of /work/product-BUILD-variant and work in that directory. No need to do a full build. If we somehow mess up, just delete this directory (you might want to save changes first, or just use mv to rename the directory) and create a new snapshot.

The actual magic happens when you use a script to update the base volume and build directories every night. It just syncs the base volume and replaces the build directory with a fresh build. Now you have a fresh build every morning with the latest changes! Again, you might want to keep a copy of the old build directory for a while just in case.

You add this to your crontab by running crontab -e and adding the following:

Wednesday, 20 January 2016

I got a new PC at work and for some reason home directory is located in /opt/home while /home is just a link to that directory.

This caused an issue with c.vim. Namely it thought I had a system-wide installation so was looking for templates under /opt/share rather than $HOME. The core issue is an if clause that checks if the script file is under $HOME. Problem was that path to the script file is under /opt/home while $HOME is set to /home and thus the script thinks it's not in the home directory.

I fixed this issue rather heavy-handedly by forcing my installation to only include local installation. I did this by editing c.vim and under the part where paths are set for Unix/Linux, removing all the stuff not needed, i.e. the if clause and everything inside else branch.

Friday, 7 November 2014

A very cool and useful way to avoid issues with working on the wrong git branch is to use the git-prompt.sh script. I sometimes manage to do this mistake. I need to check something which means changing the branch, I'm distracted and when I get back to work I forget to change the branch back. This can get messy. But with git-prompt.sh current branch is always shown in the prompt! I read about this from the Git book at http://git-scm.com/book/en/v2/Git-in-Other-Environments-Git-in-Bash which also mentions git-completion.bash. I incorporated that into my .bashrc, too, but I feel that's a lot less useful than the prompt.

Saturday, 27 September 2014

I had this annoying issue with my Ubuntu server. Every time it rebooted, quite often because of a power failure, it wouldn't boot properly. I needed to go the storage room where I have it and connect a laptop with a serial cable. Well, I got an UPS to at least stop this from happening inadvertently but I decided to fix the issue once and for all when I need to reboot it for other reasons. And it turns out that since 12.04 LTS there has been a very simple solution. Just adding the following to /etc/default/grub fixes this issue:

GRUB_RECORDFAIL_TIMEOUT=0

The problem is that if the system goes down without proper shutdown, default behaviour is to stop in the Grub menu. This is pretty ridiculous for servers.

As it happens I managed to buy the only UPS (from APC) without remote access, so I can't set the system to shutdown in case of power failure. But the UPS should be able to keep the system running for at least 30 minutes, easily, and our power failures are not that long. Think there has been one that long once and that was because our mains was cut by some workers.

Thursday, 18 September 2014

I decided to have a look at Emacs evil mode (the Vi mode for Emacs). Vim is not really suitable as an IDE. It's an editor and anything else tends to be a bit of a hack. Debugger is one such issue, it's not very convenient to use gdb inside Vim. As an added bonus I can use Lisp instead of Vimscript to write scripts.

But I like Vim's editing better than Emacs's endless control-meta-this-and-that approach. It's faster and more convenient. I might try Emacs without Evil mode at some point, I'm a pragmatist after all but at least this way I don't have to learn the entire Emacs editing thingy just to get started. I'm familiar with M-x, C-x C-f, C-x C-f and the like which should suffice for now.

Installing was almost like a breeze. Had I figured out Ubuntu 12.04 uses emacs23 instead of emacs24 which all the help I can google points to I would have had an easier time. But here's how I got started:

Now I just need to figure out how to get the same functionality as my favourite Vim plugins have. For instance, CtrlP. Someone suggested ido mode, but I can't seem to get it to do recursive search. In CtrlP you don't have to know where a file is to find it.