September 8th, 2016

ext4 encryption incompatible with grub

You encrypt a directory -- sounds easy, right? Support is in 4.4 kernel, my machines run newer kernels than that. Encrypting root would be hard, but encrypting parts of data partition should be easy.
Ok, lets follow howto... Need to do tune2fs. Right. Aha, still does not work, looks like I'll need to reboot.
Hmm. Will not boot. Grub no longer recognizes my /data partition, and that's where new kernels are. Old kernels are in /boot, but those are now useless. Lets copy new kernel on machine using USB stick. Does not boot. Fun.
tune2fs on root filesystem is useless, as it is too old. New one is ... on the data partition. Right. Ok, lets bring newer version of tune2fs in. "encryption" feature can not be cleared.
Argh! Come on, I did not even create single encrypted directory on the partition. I want the damn bit to go off, so I can go back to working configuration. "Old kernels can not read encrypted files" sounds ok, but "old kernels can not mount filesystem at all" is not acceptable here :-(.

You encrypt a directory -- sounds easy, right? Support is in 4.4 kernel, my machines run newer kernels than that. Encrypting root would be hard, but encrypting parts of data partition should be easy.
Ok, lets follow howto... Need to do tune2fs. Right. Aha, still does not work, looks like I'll need to reboot.
Hmm. Will not boot. Grub no longer recognizes my /data partition, and that's where new kernels are. Old kernels are in /boot, but those are now useless. Lets copy new kernel on machine using USB stick. Does not boot. Fun.
tune2fs on root filesystem is useless, as it is too old. New one is ... on the data partition. Right. Ok, lets bring newer version of tune2fs in. "encryption" feature can not be cleared.
Argh! Come on, I did not even create single encrypted directory on the partition. I want the damn bit to go off, so I can go back to working configuration. "Old kernels can not read encrypted files" sounds ok, but "old kernels can not mount filesystem at all" is not acceptable here :-(.
Ok, it seems it is possible to go back, as long as encryption was not actually used. fsck -fn; debugfs -w -R "feature -encrypt" /dev/device; fsck -fn;. I guess I was too optimistic. Using ext4 encryption would require at least new e2fsprogs at the root filesystem, which was something I was hoping to avoid.

25 years of Linux

25 years of linux and yes, I know Linux is popular. Still it was unexpected when I was asked in public transport if I know about Linux. Man wanted me to help with X restarting due to bad graphics drivers... I asked how he realized... and he told me about my T-shirt. I realized I have UnitedLinux T-shirt on... Given SCO's involvement in that one... should I burn the shirt?

Security getting hard/impossible on recent systems

Cache attacks: this is not good. Ok, so we have a rowhammer: basically very common, hard-to-work-around, hardware problem. Bits in your memory may flip. Deal with it.
And now, there are cache attacks, too. Users should not be able to spy on each other on multiuser system, but they very probably can. In particular, other users can tell which parts of emacs you are executing, and when. They can probably not distinguish what characters you are typing, but they can probably learn when you are typing space, normal letter, or moving cursor. Ouch. And if they indeed can spy on individual characters... you can hardly blame emacs. With plain keyboard, cache attack on individual letters is probably not feasible. With t-9 like system on touchscreen... it probably is. Deal with it. But how?