GPT, encryption and extfs support

[mrrhq]

Read before:
I am already aware of the Rockbox No-Do philosophy and why it is there, it's to keep Rockbox as simple as possible (in terms of code) and to maximize ram usage to Rockbox alone. Without further ado, put those closed, negative thoughts aside and listen to why I think support for these things is essential.

GPT:
There's no reason not to use GPT in favor of the MS-Dos partition table. Even Microsoft will be switching to GPT support with Windows 8 and UEFI. And the GUID system makes sense (at least in GNU/Linux) for organization. I'm not saying that GPT support is necessary for Rockbox, but the benefits still outweigh the losses. Not much more resources are used for GPT vs MS-Dos PT, and you can make more than 4 primary partitions, depending if Rockbox supports them all.

Extfs:
With FAT32 you can't even make lowercase labels or include some symbols in them. Most of my labels are lowercase. And FAT32 doesn't support file sizes over 4GB. Sometimes people put movies on their PMP which may be above this size, and they don't want to compress it even further by re-encoding it. I wish the amount of support for FAT32 was dropped in favor of extfs (such as ext2, ext3 and ext4...) on most devices, but it sad that I'm still required to use it. I think ext4 with the journal turned off will still be much faster and support more GNU/Linux friendly file attributes. Extfs should be a big improvement, and I don't fully see why RB isn't inclined to doing it. I really don't like FAT32 anymore at all, and I would find out any means to get rid of its existence.

Encryption:
Finally, one of the big reasons I won't use RockBox more often is because of the lack of encryption support. I want to have dm-crypt + LUKS on everything I own. Now, that being said, is this appropriate for Rockbox? Yes, it definitely can be. But is it going to work out? No, I don't think so. Here's why: There's no standard input mechanism for all players.

Typing in a potentially large password with the input mechanisms on a PMP, and still having it secure while saving time to input the password would be a real challenge. And there's entropy (strength) lost when a full keyboard is not used... God forbid if the entropy goes below 6-bits per character. And probably an extra keyfile would have to be there, but it would have to be on a decrypted partition. Maybe, on the Clip Zip, it would be on the SD Card, but not all PMP devices have support for an SD Card. That is troublesome to say the least. Now a virtual prompt with a virtual keyboard below may be a good solution to the problem.
So the password would need be stored on the device with bcrypt+SHA512 and the filesystem would be encrypted with AES 256+Blowfish or whatever is best supported and standardized.

One last thing is a hit on speed. Once it's decrypted, it would function like normal, but if people choose to use encryption, then they choose to degrade the life on their device even further (more R/W processing) among other minor things. But they can still listen to music on their device without the worry of someone stealing the unencrypted content on your device.

Anyway, thanks for reading. Sorry I cannot contribute any code because of the policy that requires having your real full name on commits. I prefer to be, at most, pseudo-anonymous. Plus, I have limited knowledge with this kind of stuff. I hope the Rockbox team will reconsider these goals. Maybe GPT support is okay to be left out, but please at least reconsider support for extfs and encryption. I hope others can agree with me.

[gevaerts]

Read before:
I am already aware of the Rockbox No-Do philosophy and why it is there, it's to keep Rockbox as simple as possible (in terms of code) and to maximize ram usage to Rockbox alone. Without further ado, put those closed, negative thoughts aside and listen to why I think support for these things is essential.

Essential? They seem to be vaguely useful for some edge cases, at most...

GPT:
There's no reason not to use GPT in favor of the MS-Dos partition table. Even Microsoft will be switching to GPT support with Windows 8 and UEFI. And the GUID system makes sense (at least in GNU/Linux) for organization. I'm not saying that GPT support is necessary for Rockbox, but the benefits still outweigh the losses. Not much more resources are used for GPT vs MS-Dos PT, and you can make more than 4 primary partitions, depending if Rockbox supports them all.

For one, most of the players we support won't even boot without a valid MBR partition table. I'd say that's a fairly major issue, but feel free to disagree. Also, why do you need more than four partitions in rockbox anyway?

If the lack of GPT ever actually becomes an issue, I'm sure we'll add support for it. Today though, I don't see any reason for it apart from "Wouldn't it be nice to support more stuff?"

Extfs:
With FAT32 you can't even make lowercase labels or include some symbols in them. Most of my labels are lowercase. And FAT32 doesn't support file sizes over 4GB. Sometimes people put movies on their PMP which may be above this size, and they don't want to compress it even further by re-encoding it. I wish the amount of support for FAT32 was dropped in favor of extfs (such as ext2, ext3 and ext4...) on most devices, but it sad that I'm still required to use it. I think ext4 with the journal turned off will still be much faster and support more GNU/Linux friendly file attributes. Extfs should be a big improvement, and I don't fully see why RB isn't inclined to doing it. I really don't like FAT32 anymore at all, and I would find out any means to get rid of its existence.

Dropping FAT32 is not an option. Many DAPs (though admittedly not all) require a FAT32 partition to even boot. Apart from that, you lose support for functional dual-boot (which many people use), and you lose support for any host OS that doesn't deal with ext* properly. This means that if you're ever going to see ext*, it will be in addition to FAT32.

That said, are you aware that rockbox does not support any video format apart from mpeg1/2, at the resolution of the device? If there is a non-contrived mpeg2 file around for 320x240 that's larger than 2GB or 4GB (the FAT32 size limitation is a bit vague), I'd like to see it.

If you claim that adding ext* support would be reasonable, I'd like to see some sort of analisys of expected RAM use at least.

Encryption:
Finally, one of the big reasons I won't use RockBox more often is because of the lack of encryption support. I want to have dm-crypt + LUKS on everything I own. hNow, that being said, is this appropriate for Rockbox? Yes, it definitely can be. But is it going to work out? No, I don't think so. Here's why: There's no standard input mechanism for all players.

Typing in a potentially large password with the input mechanisms on a PMP, and still having it secure while saving time to input the password would be a real challenge. And there's entropy (strength) lost when a full keyboard is not used... God forbid if the entropy goes below 6-bits per character. And probably an extra keyfile would have to be there, but it would have to be on a decrypted partition. Maybe, on the Clip Zip, it would be on the SD Card, but not all PMP devices have support for an SD Card. That is troublesome to say the least. Now a virtual prompt with a virtual keyboard below may be a good solution to the problem.
So the password would need be stored on the device with bcrypt+SHA512 and the filesystem would be encrypted with AES 256+Blowfish or whatever is best supported and standardized.

One last thing is a hit on speed. Once it's decrypted, it would function like normal, but if people choose to use encryption, then they choose to degrade the life on their device even further (more R/W processing) among other minor things. But they can still listen to music on their device without the worry of someone stealing the unencrypted content on your device.

I don't think support for encrypted partitions is a NoDo. It's a lot of work though, and getting it to work fast enough on a typical DAP to be usable at all is going to be a tough challenge. Patches welcome, I'd say.

Anyway, thanks for reading. Sorry I cannot contribute any code because of the policy that requires having your real full name on commits. I prefer to be, at most, pseudo-anonymous. Plus, I have limited knowledge with this kind of stuff. I hope the Rockbox team will reconsider these goals. Maybe GPT support is okay to be left out, but please at least reconsider support for extfs and encryption. I hope others can agree with me.

The Rockbox team does not have goals. We have some consensus on what is and isn't appropriate, but that's about it.

[saratoga]

Ext seems pretty useless but I guess exfat might make sense eventually if it ever takes off.