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 crypt2However, 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.