Initializing dm-crypt on Android results in "device lookup failed"

Hello,

I am currently trying to track down an issue with dm-crypt on an Android device (more specifically, I am building a CM 12.1 ROM), where initializing device encryption fails with an error.

I have asked this question in a number of other places as well (stackoverflow and xda), but have not gotten any responses. I therefore decided to ask the question on a list more directly connected to dm-crypt. It is if course entirely possible that the error lies somewhere in the device-mapper, but in that case my hope is still that somebody on this list is familiar enough with the device-mapper and its interaction with dm-crypt to point me to a potential solution.

So here is the problem: when starting the device encryption, the encryption itself fails with the following error:

01-01 03:20:02.631 I/Cryptfs ( 254): Using scrypt for cryptfs KDF

01-01 03:20:03.592 I/Cryptfs ( 254): Enabling support for allow_discards in dmcrypt.

01-01 03:20:03.592 I/Cryptfs ( 254): load_crypto_mapping_table:
target_type = crypt

01-01 03:20:03.592 I/Cryptfs ( 254): load_crypto_mapping_table:
real_blk_name = /dev/block/platform/mtk-msdc.0/by-name/userdata, extra_params = 1 allow_discards

01-01 03:20:03.592 I/Cryptfs ( 254): load_crypto_mapping_table:
crypt_params = aes-cbc-essiv:sha256 0A66F89B0D3DFC0B05D9BD23B3453A70 0 /dev/block/platform/mtk-msdc.0/by-name/userdata 0 1 allow_discards 0

01-01 03:20:08.619 E/Cryptfs ( 254): Cannot load dm-crypt mapping table.

at the same time, the kernel log prints the following messages:

<3>[  138.163773] (5)[327:vold]device-mapper: table: 253:0: crypt:
Device lookup failed
<4>[  138.163781] (5)[327:vold]device-mapper: ioctl: error adding target

to table

Unfortunately, the device I am testing this with has not had the kernel sources released, so I only have a prebuilt kernel (3.10.61) that I cannot recompile. However, another ROM using the same kernel (IIRC) can successfully encrypt the device, so I don't think it is anything inherent in the kernel itself. But I am at a loss what else could be the problem.

I'd be happy to provide any additional information as needed.

Any help or pointers in solving this issue would be greatly appreciated. Thanks!

Best regards,

Roman

Hello Roman,

I'm no Android developer, so just according to what I can see in your logs:

Don't post your volume key publicly! If it was just a test device it's not so big deal but it's generally good rule to follow so that you don't post your VK for real device accidentally.

</mentoring_mode>

The kernel driver complaints that it can't access a block device referenced by path /dev/block/platform/mtk-msdc.0/by-name/userdata. Is it block device? If it's supposed to be a symlink does a referenced block device exist?

The thing is kernel accepts only limited set of paths as device identifier in DM table. Usually major:minor numbers, kernel path, part_uuid. The translation from arbitrary path '
/dev/block/platform/mtk-msdc.0/by-name/userdata' to something DM driver is able to parse should be done in userspace. Usually, it's libdevmapper library what does that. Given that kernel complaints, it seems userspace haven't done the translation properly or there was a race maybe. Could you pass major:minor for /dev/block/platform/mtk-msdc.0/by-name/userdata directly in userspace utility that's supposed to establish device encryption?

Regards
Ondrej

Hi Ondrej,

Thanks a lot for your reply.

I was aware that the log contained the volume key (it is a test device), but you're of course right that I should not get in the habit of posting it :-).

The device /dev/block/platform/mtk-msdc.0/by-name/userdata is actually a symbolic link to another block device, but it seems to exist at the time of encryption.

What exactly do you mean with that there might be a race?

Thanks and best regards,

Roman

...

I really hope Android does not log volume key such a way to system log...

This message seems to indicate that problem is with device specification:
/dev/block/platform/mtk-msdc.0/by-name/userdata

Can you check, that such device node exists before calling this activation?

You can try to use "major:minor" pair instead (of the device above), but it can sause problem if it is dynamic (it shouldn't be in this environment though).

Milan
p.s.

The situation in Android world is really not good. Some major vendors even reimplemented dm-crypt with hardcoded algorithms to speed up on their crappy hw. Obviously without contact mainline kernel developers, and breaking all other interfaces as a side effect etc.
So do not be surprised that we will ignore any support questions if someone is doing such things, nobody really know what source code was used to compile the kernel.

Hi Milan,

Thanks a lot for your reply.

No, it doesn't :-). That's the testing output I added to vold to check that it wasn't a problem with the parameters submitted to dm-crypt.

I checked, and the /dev/block/platform/mtk-msdc.0/by-name/userdata is a symbolic link to /dev/block/mmcblk0p17, which seems to be a real block device. And both exist at the time when the encryption process is started (and the symbolic link is valid).
As a first step I tried to submit the actual block device (i.e., /dev/block/mmcblk0p17) as a parameter, but it still fails with the exact same error.
I'll now try to pass the major:minor pair to see if that works.

For what it is worth, when trying to narrow down the problem in the last few days, I think I could track it down to a function call in dm-crypt.c in the kernel, namely in the function crypt_ctr():

...

	if (dm_get_device(ti, argv[3], dm_table_get_mode(ti->table), &cc->dev)) {
		ti->error = "Device lookup failed";
		goto bad;
	}

...

Within the called function (dm_get_device() in dm-table.c), I can't really tell where the error happens, I think it could be any of the following three lines:

struct block_device *bdev = lookup_bdev(path);

if ((r = open_dev(dd, dev, t->md))) { ... }

r = upgrade_mode(dd, mode, t->md);

But where exactly I cannot say just from the source code, and an error in any of these produces the same "Device lookup failed" in userspace.

I completely understand, which is why I am very thankful for all the replies. They have released the source code for the same model of phone, but with a different chipset (i.e., they have released the source for the model with the Qualcomm Snapdragon CPU, but not the source for the model with the MTK CPU, which is the one I have).

Thanks a lot again and best regards,

Roman

Hi,

I just tried passing the major:minor of the device, instead of a device path, but I am still getting the same error, "Device lookup failed".

Any further hints on what could be the issue would be very much appreciated...

Thanks and best regards,

Roman