Replying to myself, I started reading in the original Volla phone kernel sources. Looking at dm-crypt.c it seems that it has patches that add some very specific (and broken) hacks to accommodate Mediatek hardware encryption (everything that depends on CONFIG_MTK_HW_FD which is set on the Volla's phone kernel).
This function seems to be the culprit. It escapes me how anybody could throw this kind of hack into a production kernel:
/*
* MTK PATCH:
*
* Get storage device type (for hw fde on/off decision)
* or id (for crypt_config).
*
* Returns:
* 0: Embedded storage, for example: eMMC or UFS.
* 1: External storage, for example: SD card.
* -1: Unrecognizable storage.
*/
static int crypt_dev_id(const char *path)
{
int type = -1;
if (strstr(path, "bootdevice")) {
/* example: /dev/block/platform/bootdevice/by-name/userdata */
type = 0;
} else if (strstr(path, "externdevice") || strstr(path, "vold")) {
/* example: /dev/block/vold/private:179,2 */
type = 1;
}
pr_info("[dm-crypt] dev path: %s, type: %d\n", path, type);
return type;
}
So whenever you are trying to device-map some block device that does not have any of the substrings "bootdevice" or "vold" or "externdevice" in them, this returns -1, which in turn will break any attempts to use such a device in the device-mapper, thanks to the over-strict check added in crypt_ctr():
cc->id = ret = crypt_dev_id(argv[3]);
if (ret < 0)
goto bad;
Note how e.g. any loop device /dev/loop* will thus fail. However, this also allows a workaround. We just use a different name (with the same major/minor device numbers) that matches 'externdevice'. This way dmsetup will magically start working:
cp -a "${LODEV}" /dev/externdevice1
echo "0 128 crypt aes-ecb 0123456789abcdef0123456789abcdef 0 /dev/externdevice1 0" | dmsetup create crypt2
However, I am not sure whether this kind of workaround could be applied to 'cryptsetup'.
This really destroys any illusion WRT to code-quality of the kernels that is running the Volla phone.
