Open finasfinas opened 6 years ago
This option does not cause overhead
You mean it causes minimal runtime overhead if not in use.
At minimum, if you're not using the VFS encryption API, you're still going to take a few extra CPU cycles in many VFS operations (at least read and write calls) to determine if the file being operated on is encrypted or not, and it will still increase the runtime memory footprint of the kernel.
Beyond that, I do agree with your points about usability being far better than FDE (LUKS or otherwise), and would like to add that it's not just ext4 that supports this (F2FS has support too, and there's some talk of adding it to other filesystems as well).
yes, I was refering to no overhead when not in use. When in use it's still cheaper to run than all the others except maybe loop-aes.
Anyway, it's an easy fix, and at least from my point of view a no brainer to just add support in the kernel and problem solved as it has no drawbacks at all.
@popcornmix @pelwell Any thoughts on this?
Considering the time that has passed without an answer, maybe this is not the right place to post a bug report. Does the project have a bug tracker where a bug report can be filled?
This is the correct place for linux kernel bug reports and requests for kernel changes.
Note though that 21 days is not a long time - we've issues on here that are lots older than that!
What we really want to know is what the overheads are (you say there are none but that doesn't sound possible - something must change). So what is the performance hit on the low end machines (Pi1, Zero etc), both in cycles and memory?
As this is a built-in option (rather than a kernel module) it will have an effect on kernel size and memory usage for all users (whether they use it or not).
This means it needs more thought in weighing up cost/benefit before enabling.
Useful information for this decision is kernel.img size before and after this change and free memory (free -h
) after boting with/without this change.
Using bcr2835_defconfig (that is the default for the ARMv7 Pi's right?) with the rpi-4.14.y branch as of right now, kernel size without this is 4602k.
Using an otherwise identical configuration with this enabled, kernel size is 4640k.
If we do the smart thing and update the config to use the ext4 driver for ext2 and ext3 (CONFIG_EXT2_FS=n
, CONFIG_EXT3_FS=n
, and CONFIG_EXT$_USE_FOR_EXT2=y
), then a decent percentage of that size increase can be recouped (making these changes in addition to enabling FS encryption results in a kernel image size of 4617k).
I've got no data right now for runtime memory usage unfortunately, as I don't have any spare Pi's to check on right now, but I don't think it will be all that bad (I'd expect it's maybe a few hundred kB difference at most to just enable this, and would probably be a net decrease if we change to using the ext4 driver for ext2 and ext3).
@Ferroin Did you manage to get any run time figures?
Unfortunately not anything native. I just did some testing over the weekend in a QEMU VM running an emulated ARMv7a CPU equivalent to the Pi 2 on an x86 host, and the performance difference between not having VFS encryption enabled at all, and having it built in but unused was less than 1% (about 0.2-0.4% in most cases, though I expect that to be much lower on the Pi because I/O is much slower there than it was in the VM). In pretty much all cases, it required looking at numbers from batches of thousands of I/O operations to produce a performance difference measurable from userspace without needing to use perf
.
@popcornmix Is that enough information or would we still want some runtime memory data?
@popcornmix @pelwell Any further thoughts on this, or flag up for 30 day close?
The issue title is now out-of-data, but the same issue applies to our 4.19 defconfigs. I'm inclined to trust @Ferroin's analysis of the performance impact and possible mitigation - we could make these changes to bcm2709_defconfig and bcm2711_defconfig, leaving the smaller-memoried BCM2835-based devices without, but perhaps the actual impact is small enough that this differentiation isn't worthwhile.
Looks like we already have the CONFIG_EXT2_FS=n
, CONFIG_EXT3_FS=n
, and CONFIG_EXT4_USE_FOR_EXT2=y
so I guess the cost is the 38K.
So I am using Rasbian Buster (10.3) with kernel 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020
and I install and setup fscrypt
.
I am using Synology NAS as iSCSI target and I mount it as ext4 device.
Of course, earlier I said:
sudo mkfs.ext4 -O encrypt -b 4096 /dev/sdd1
sudo e2label /dev/sdd1 SynologyiSCSI
Then I say fscrypt setup /media/SynologyNAS
, and life seems to be good:
Metadata directories created at "/media/SynologyNAS/.fscrypt".
Filesystem "/media/SynologyNAS" (/dev/sdd1) ready for use with ext4 encryption.
But not good enough! fscrypt status
says:
filesystems supporting encryption: 0
filesystems with fscrypt metadata: 1
MOUNTPOINT DEVICE FILESYSTEM ENCRYPTION FSCRYPT
/boot /dev/mmcblk0p1 vfat not supported No
/media/SynologyNAS /dev/sdd1 ext4 not enabled Yes
Now as I suspected:
mkdir /media/SynologyNAS/encrypted
and then:
fscrypt encrypt /media/SynologyNAS/encrypted
I get the unpleasant answer:
fscrypt encrypt: get encryption policy /media/SynologyNAS/encrypted: encryption not enabled
Encryption is either disabled in the kernel config, or needs to be enabled for this filesystem. See the documentation on how to enable encryption on ext4 systems (and the risks of doing so).
Why, oh why?
Well, because:
ls /sys/fs/ext4/features/
says only: batched_discard lazy_itable_init meta_bg_resize metadata_csum_seed
, and not encryption
.
So... my question is. How to enable CONFIG_EXT4_ENCRYPTION in Raspbian Buster?
And when will our little "buster" get the EXT4 encryption support?
CONFIG_EXT4_USE_FOR_EXT2
is already set (it defaults to y
), so there is nothing to be gained there. Setting CONFIG_EXT4_ENCRYPTION=y
and looking at the change in location of symbol _end
(as a measure of how much the kernel overall has grown, excluding dynamic allocations) shows the following increases:
I'm reluctant to consume 68KB of (for some models) 128MB RAM for a feature that is unlikely to be used by many, but I've enabled the feature for all kernels except kernel.img - see 3447fe2.
a feature that is unlikely to be used by many, but I've enabled the feature for all kernels except kernel.img
Thanks for enabling. Wanted to encrypt data to a 5 TB USB3 Drive and noticed this issue too
Support for native ext4 encryption has been added to the kernel since version 4.1. It is enabled with CONFIG_EXT4_ENCRYPTION=1
A running kernel can be checked for support by looking at the existence of the following file: /sys/fs/ext4/features/encryption If this file does not exist, then the kernel has been compiled without the CONFIG_EXT4_ENCRYPTION option and thus has no native ext4 encryption support.
This option does not cause overhead and brings significant gains in ease of use and performance when compared with other options like luks+ dm-crypt, etc.
Userland tools to create and mount an encrypted ext4 filesystem are already present as the version shipped of efsutils already has support for this.
please add support in the kernel for native ext4 encryption.