Allowing to boot a non-encrypted rootfs when encryption is enable is a security
hole: if an attacker can somehow write (offline) to the media, he could flash a
custom unencrypted rootfs and break into the system.
If the system is configured to use encryption, only encrypted rootfs will boot.
Trying to boot a non-encrypted rootfs will fail and power off the device.
https://jira.digi.com/browse/DEL-3829
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
The recovery ramdisk already contains functionality for encrypted rootfs
installation. The goal is to centralize all this functionality in the recovery
ramdisk.
https://jira.digi.com/browse/DEL-3829
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
New functionality has been implemented in trustfence-tool application,
so there is no need to call cryptsetup command.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Get filesystem type of rootfs block device and pass it explicitly to the
mount command to clean following warnings on boot:
EXT4-fs (dm-0): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (dm-0): couldn't mount as ext2 due to feature incompatibilities
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This package adds some files needed by the trustfence initramfs and that
are not included in other packages.
https://jira.digi.com/browse/DEL-2278
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Tatiana Leon
Alex Gonzalez
Javier Viguera