FS#51879 - [grub] fails with ext4 and encrypt feature in /boot

Attached to Project: Arch Linux
Opened by Rodrigo Rivas Costa (rodrigorc) - Friday, 18 November 2016, 19:29 GMT
Last edited by Christian Hesse (eworm) - Friday, 08 September 2017, 10:11 GMT
Task Type Feature Request
Category Upstream Bugs
Status Closed
Assigned To Ronald van Haren (pressh)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Grub does not recognizes the "encrypt" feature in ext4 filesystems. That makes the system totally unbootable if /boot is in such a system.
And since tune2fs cannot be used to remove that feature, only to insert it, you will have a bad time restoring the system.

I'm sure that the Grub people are working on it, but in the meantime, I have written a quick patch to be able to boot, attached.

Additional info:
* 1:2.02.beta3-4

Steps to reproduce:
* Enable the feature in your filesystem where /boot is: "tune2fs -O encrypt /dev/sdxx".
* Reboot the system, it will fail
* To restore the system, reboot with a ArchISO and do: "debugfs -w -R 'feature -encrypt' /dev/sdxx"
   ext4-encrypt.patch (1.9 KiB)
This task depends upon

Closed by  Christian Hesse (eworm)
Friday, 08 September 2017, 10:11 GMT
Reason for closing:  Implemented
Additional comments about closing:  grub 2:2.02-2
Comment by Doug Newgard (Scimmia) - Saturday, 19 November 2016, 15:51 GMT
Sounds more like an unimplemented feature than a bug.
Comment by Christian Hesse (eworm) - Sunday, 20 November 2016, 00:25 GMT
This just moves the problem a step further, no? Grub tries read the filesystem, but fails if /boot actually is encrypted. I suppose it will print something like "file not found", not giving any hint about encrypting.
Probably we should wait for upstream to provide a proper solution.
Comment by Rodrigo Rivas Costa (rodrigorc) - Sunday, 20 November 2016, 14:18 GMT
Well, ext4 encrypt feature is actually a per-directory option. That is, you enable the feature in the filesystem, and then you are able to encrypt selected directories.
My patch just accepts the filesystem feature and then ignores the encrypted directories content, so it is able to boot the system.

Of course, if the /boot directory itself is encripted it will not work. For that you'd need to implement the decrypt functionality and add the password somewhere...
But I don't think that is the normal use case for this feature (and I'm not up to patching that). I think that it is intended to encrypt the `/home/user` or the `/home/user/secret` or something like that. Not `/` or `/boot`.

@Doug:
> Sounds more like an unimplemented feature than a bug.

From the Grub POV, sure. But from the Arch user POV, now I have this fancy new feature [1] that will make my system unbootable. I'd say that this is a distribution bug.


[1]: https://wiki.archlinux.org/index.php/Ext4#Using_ext4_file-based_encryption
Comment by David McAdoo (geecroof) - Wednesday, 06 September 2017, 16:34 GMT
Official patch is already in grub master git. Can we backport it to our package? Grub official releases aren't much frequent so it can take years before next release.

https://git.savannah.gnu.org/cgit/grub.git/commit/?id=734668238fcc0ef691a080839e04f33854fa133a

Loading...