Topics created by Dave

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.

@flohack yes I had similar reservations which kept me from trying this. However, looking at the recipes documented here (i.e. mostly the shell script fragments by @chrisc and @c4pp4), this looks quite doable.

They're just encrypting /home/phablet. After reboot /home/phablet is non-encrypted. You run a shell-script to replace it with a dm-crypt encrypted loopback block device and restart the lightdm session. Still quite cumbersome, but still better than no encryption at all.

Maybe adding a launcher as described here for running the crypto-mount script in the terminal will make this more practical.

I'm not yet done setting this up, as I was set back by that Mediatek related dm-crypt bug in the kernel that ships on the Volla Phone. But no real show-stoppers so far.

@dobey said in Security of data and passwords when phone is lost/stolen:

This is only true if the bootloader is already unlocked, or the device has a bug where unlocking the bootloader does not perform a system reset and destroy all data. Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.

You're right. Completely forgot that unlocking forced a wipe. Thanks for the correction.

Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.

Yes, that process is what I'm referring to when I say unlocking must be authorized from within the stock OS before it can be done to newer devices. (i.e., "must be flagged as unlockable from within developer settings" in the earlier post. I probably should have added the word "manually" before "flagged" to make that clear.)

Hi @advocatux ,

I ran into the same "signature error", attempting to update my Aquaris 10 FHD tablet. As I don't mind breaking the tablet (as opposed to my phone), I just attempted to upgrade using the development channel, which worked (i.e. no signature error), then once that was running switched back to the stable image, and this time no signature error as well.

Working nicely now, no problems, some bugs I encountered with 15.04 seem to be fixed with that release. Very happy. Will attempt the same procedure on my phone.

Dave

@Dave I think most of those issues will have been covered already as the update to 16.04 is nearly a year old now. I would get upto date with everything and check all is ok and go from there. If you are still having issues please come back here for help.

@advocatux said in Community infrastructure: Forum and Telegram:

@guru said in Community infrastructure: Forum and Telegram:

+1 for using the (existing) mailing-list as primary channel for technical discussions and support.

Are you talking about the UBports's ones or the old Canonical's Ubuntu-Phone list?

Both would do the job. The old one even better because a lot of UT users are still subscribed there and would may be encouraged to move to the UBports devices.

I'm pretty sure that the installer does not touch the partition layout.

Remember

Android is weird. I wouldn't be surprised if some devices/bootloaders have specific expectations about the partition layout these are embedded devices. If the bootprocess is severly messed up, you can't exactly put the hard disk into that other device and fix the partitions

So, while I guess it is possible to make cache smaller, I am not gonna try on my device and I'd caution you to do so!

Now to the aspect of "I'm running out of space" due to tinkering with libertine, ... well you still have some 6GB to through around, not huge, but not nothing either. If you run out of space, rather than doing acrobatics with partition sizes you want to look into acrobatics with bind mounting 😉

You could try and if it works document it here

https://docs.ubports.com/en/latest/userguide/dailyuse/libertine.html

I'd also try first with a symlink, but if that gives any problems, I would assume a bind mount should work. but then you have the additional challenge of having to reestablish the mount after every reboot. maybe it can be automated with upstart.