Add support for encryption

[chenxiaolong]

General procedure:

1. Have the app automatically parse the /system/bin/vold and /system/bin/vdc ELF binaries and find all of the dependencies and store them in cache. (NOTE: May need hardcoded list of additional device-specific binaries)
2. Have mbtool attempt to mount data. If it fails, mount a tmpfs to /system and /cache (to avoid accidental factory reset via /cache/recovery/command), extract the vold archive, set up the properties environment, and run vold. It might be necessary to preload an appropriate liblog.so since there will be no logcat daemon running.
3. Connect to the vold daemon and get the password type via cryptfs getpwtype command. If the daemon returns a syntax error code, assume the device is pre-Lollipop and offer password input only. Otherwise, the password type will be one of: password, default, pattern, pin. The result will be used to determine the appropriate screen to show in the Boot UI. (NOTE: Pattern -> password conversion differs between ROMs. The user may need to set the Android version on the Boot UI screen.)
4. Generate an fstab file with just the /data partition entry and remove the forceencrypt vold option. Attempt to decrypt the partition using the cryptfs checkpw <PASSWORD> command.
5. vold will mount the partition to /data. mbtool will bind mount /data to /raw/data and then umount /data.
6. All processes other than PID 1 should be killed.

Additional notes:

• mbtool will handle the connection to vold, not Boot UI. It will essentially act as a proxy so the Boot UI can be abstracted away from all of the details.

---

The needed files will need to be manually listed and many devices will need a setup script to start, eg. Secure Storage and Mobicore (on Samsung devices).

The setup script would be something like:

#!/system/bin/sh

set -x

export PATH=/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export LD_LIBRARY_PATH=/vendor/lib:/system/lib

# Enable use of the SS daemon
setprop ro.securestorage.support true

# The daemons use these symlinks
ln -s /system/etc /etc
ln -s /system/vendor /vendor

# Mountpoints for the 
mkdir /efs
mkdir /firmware
mkdir /firmware-mdm

# Create temporary paths needed by the daemons
mkdir -p /dev/.secure_storage
mkdir -p /data
mkdir -p /data/app
mkdir -p /data/app/mcRegistry

# Wait for block devices
for path in /dev/block/platform/msm_sdcc.1/by-name/apnhlos \
            /dev/block/platform/msm_sdcc.1/by-name/mdm \
            /dev/block/platform/msm_sdcc.1/by-name/efs; do
    until [ -e "${path}" ]; do
        sleep 1
    done
done

# Mount partitions
mount -t vfat -o ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware:s0 \
    /dev/block/platform/msm_sdcc.1/by-name/apnhlos \
    /firmware
mount -t vfat -o ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware:s0 \
    /dev/block/platform/msm_sdcc.1/by-name/mdm \
    /firmware-mdm
mount -t ext4 -o nosuid,nodev,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic \
    /dev/block/platform/msm_sdcc.1/by-name/efs \
    /efs

# Required by vold
# Originally from: /system/bin/prepare_param.sh
ln -s /dev/block/platform/msm_sdcc.1/by-name/param /dev/block/param

#/system/bin/sh /system/etc/init.qcom.modem_links.sh

# Required by vold
/system/bin/secure_storage_daemon &

# Mobicore stuff
# Originally from: /system/bin/mobicore-{presetup,startup}.sh

/system/bin/mcStarter

# set device node permissions for TLC apps
chmod 700 /dev/mobicore
chmod 666 /dev/mobicore-user

# mobicore trustlets
for i in ffffffff000000000000000000000005.tlbin \
         ffffffff000000000000000000000006.tlbin \
         ffffffffd00000000000000000000006.tlbin \
         07010000000000000000000000000000.tlbin \
         ffffffff000000000000000000000009.tlbin \
         ffffffff000000000000000000000008.tlbin \
         ffffffff000000000000000000000004.tlbin \
         ffffffffd00000000000000000000004.tlbin; do
    ln -s "/system/app/mcRegistry/${i}" "/data/app/mcRegistry/${i}"
done

# Run daemon in background
/system/bin/mcDriverDaemon -r /system/app/mcRegistry/FFFFFFFF000000000000000000000001.drbin &

(MAYBE) Also require a script to perform the decryption procedure. I've already implemented a vold client in mbtool, but the script could call vdc (or anything else) and handle any vendor modifications to vold.

During boot, mbtool should create a temporary root, extract the file archive into it, bind mount /dev, /proc, and /sys into it, and run the processes in the chroot. The processes should probably run in a cgroup. After the decrypted devmapper node has been created, kill all processes in the cgroup, recursively unmount everything in the temp root, and delete the temp root. Then mount the devmapper file to /raw/data.

During boot, mbtool should create a temporary root, bind mount /raw/system to /system inside of it, bind mount /dev, /proc, and /sys into it, and run the processes in the chroot. The processes should probably run in a cgroup. After the decrypted devmapper node has been created, kill all processes in the cgroup, recursively unmount everything in the temp root, and delete the temp root. Then mount the devmapper file to /raw/data.

[chenxiaolong]

Based on my findings today, I believe that creating an archive with vold and all its dependencies is a bad idea. vold pulls in way too many dependencies (105 files in total for the SGH-M919 stock ROM). And that don't include any binaries needed for the execution of the setup script. Adding support for hardware encryption is already difficult enough. There's no reason to require maintainers to produce a complete list of every file required to make encryption work. Instead, we'll require that the user's primary ROM be compatible with the encryption scheme. That way, mbtool can create a temp chroot during boot, mount the primary ROM, and execute the encryption setup script there. This also means the user-experience will be significantly better than originally proposed since no further action besides the ramdisk update and the Boot UI installation is required.

Example file list for the SGH-M919 (jfltetmo) stock ROM: (Why the heck is libemoji.so pulled in by vold?)

# Dynamic linker
/system/bin/linker

# Shell
/system/bin/sh

# Vold
/system/bin/vold

# Secure storage
/system/bin/secure_storage_daemon

# Mobicore
/system/bin/mcDriverDaemon
/system/bin/mcStarter
/system/app/mcRegistry/ffffffff000000000000000000000005.tlbin
#/system/app/mcRegistry/ffffffff000000000000000000000006.tlbin
#/system/app/mcRegistry/ffffffffd00000000000000000000006.tlbin
/system/app/mcRegistry/07010000000000000000000000000000.tlbin
/system/app/mcRegistry/ffffffff000000000000000000000009.tlbin
/system/app/mcRegistry/ffffffff000000000000000000000008.tlbin
/system/app/mcRegistry/ffffffff000000000000000000000004.tlbin
/system/app/mcRegistry/ffffffffd00000000000000000000004.tlbin

# Shared libraries
/system/lib/libandroid_runtime.so
/system/lib/libandroidfw.so
/system/lib/libaudioutils.so
/system/lib/libbcc.so
/system/lib/libbcinfo.so
/system/lib/libbinder.so
/system/lib/libc.so
/system/lib/libcamera_client.so
/system/lib/libcamera_metadata.so
/system/lib/libcc_manager.so
/system/lib/libcorkscrew.so
/system/lib/libcrypto.so
/system/lib/libcutils.so
/system/lib/libdirencryption.so
/system/lib/libdiskconfig.so
/system/lib/libdl.so
/system/lib/libEGL.so
/system/lib/libemoji.so
/system/lib/libepm.so
/system/lib/libETC1.so
/system/lib/libexpat.so
/system/lib/libext2_blkid.so
/system/lib/libext2_com_err.so
/system/lib/libext2_e2p.so
/system/lib/libext2_uuid.so
/system/lib/libext2fs.so
/system/lib/libext4_utils.so
/system/lib/libft2.so
/system/lib/libgabi++.so
/system/lib/libgccdemangle.so
/system/lib/libGLES_trace.so
/system/lib/libGLESv1_CM.so
/system/lib/libGLESv2.so
/system/lib/libgui.so
/system/lib/libhardware.so
/system/lib/libhardware_legacy.so
/system/lib/libharfbuzz_ng.so
/system/lib/libhwui.so
/system/lib/libicui18n.so
/system/lib/libicuuc.so
/system/lib/libinput.so
/system/lib/libjpeg.so
/system/lib/libkeyutils.so
/system/lib/libknox_encryption.so
/system/lib/libLLVM.so
/system/lib/liblog.so
/system/lib/liblogwrap.so
/system/lib/libm.so
/system/lib/libmaet.so
/system/lib/libMcClient.so
/system/lib/libmedia.so
/system/lib/libmemtrack.so
/system/lib/libnativehelper.so
/system/lib/libnetutils.so
/system/lib/libomafldrm.so
/system/lib/libpersona.so
/system/lib/libpng.so
/system/lib/libQSEEComAPI.so
/system/lib/libquramimagecodec.so
/system/lib/libremotedesktop_client.so
/system/lib/libRS.so
/system/lib/libRScpp.so
/system/lib/libsamsungeffect.so
/system/lib/libsec_devenc.so
/system/lib/libsec_ecryptfs.so
/system/lib/libsec_km.so
/system/lib/libsec_ode_km.so
/system/lib/libsecfips.so
/system/lib/libsecnativefeature.so
/system/lib/libsecure_storage.so
/system/lib/libSecurityManagerNative.so
/system/lib/libselinux.so
/system/lib/libsensorhub.so
/system/lib/libskia.so
/system/lib/libskmm.so
/system/lib/libsonivox.so
/system/lib/libsparse.so
/system/lib/libspeexresampler.so
/system/lib/libsqlite.so
/system/lib/libssl.so
/system/lib/libstagefright_foundation.so
/system/lib/libstdc++.so
/system/lib/libstlport.so
/system/lib/libsxqk_skia.so
/system/lib/libsync.so
/system/lib/libsysutils.so
/system/lib/libTimaAL.so
/system/lib/libui.so
/system/lib/libusbhost.so
/system/lib/libutils.so
/system/lib/libwpa_client.so
/system/lib/libz.so

[Caio99BR]

This support is really needed?

[chenxiaolong]

Yeah. Just about every middle to high-end device is shipping with forced encryption now. Users shouldn't have to wipe data and flash a custom kernel just to disable encryption.

[Caio99BR]

Oh ok, i only have low-end devices, that's why this not is important for me :P So the implementation is initialize basic system, decrypt, kill basic system, do something and continue like nothing happen?

[chenxiaolong]

Yep, that's correct :P

[Caio99BR]

Other thing, it's because BootUI or all the MultiBoot?

[chenxiaolong]

It's a bit of both. mbtool will handle all the steps for decryption and the Boot UI will display the password/pin/pattern/etc. dialog and send the password to mbtool. Nothing will change for the app or user experience.

[chenxiaolong]

The encryption branch will be merged, but the functionality will be disabled for now. DualBootPatcher goes through a lot of effort to start vold so we can leverage the manufacturer's own encryption code. Unfortunately, this is very error-prone, especially on Samsung devices where the Secure Storage daemon cannot communicate with the TEE if a custom kernel is used. On the S4, Secure Storage can be disabled, but this is no longer the case on newer devices.

Since this method doesn't work very well, I'm likely just going to use TWRP's crypto code, which means only AOSP encryption will be supported. It'll vastly reduce the complexity with the current implementation.

[chenxiaolong]

The new implementation has been completed and merged into master.