Full-Disk-Encryption (FDE) on HC-2

[gnome_shell]

Hey everybody,

I know how to fully encrypt a usual Linux system but I wonder how to fulfill this task on the ODROID-HC2 as it has no GRUB2 at all. I also don't know if it' even possible to boot a Linux live USB for debugging/repairing reasons. Is there any tutorial that will explain in detail how to install the latest Ubuntu image (offered by hardkernel in the download page) and using full disk encryption ?

any help appreciated. Thanks

[igorpec]

You can try this route:

Code: Select all

CRYPTROOT_ENABLE ( yes | no ): enable LUKS encrypted rootfs

https://docs.armbian.com/Developer-Guide_Build-Options/
haven't test it personally, don't know if it works with HC2, but some got it working in some combination of hardware / userland.

Those single board computers are somewhere between custom embedded Linux and what people are used to on their PC. Regardless how things looks like from the user perspective ("Ubuntu", "Debian", ...)

No, its not possible to boot from USB just like that. For debugging you need a serial console and / or another SD card with a system. In most cases we have live system, which can be transferred from that SD card to eMMC / SSD if you like. Or access HDD in case of HC2.

[gnome_shell]

Hi Igor,

Will this work on Ubuntu image? Actually I cannot and won't use the Armbian image any more because it failed in several tests I made last week. The armbian image (tested Buster and Bullseye) both already fail the iperf test which shows only 600 MBit/s of the expected 900 MBit/s. The throughput is horrible bad. As odroid replied, Armbian is not tested and supported for the ODROID-HC2 and only the Ubuntu image is maintained.

So my question is --> how to Full-Disk-Encryption on the latest Ubuntu image for the ODROID-HC ?

I really would love to have the ability to full-encrypt my 3.5" HDD on the ODROID-HC2 and encrypt it using a prepared USB key with the LUKS key for this purpose. But I want the OS fully-encrypted on the 3.5" disk so all the root (/) lies on the LUKS-encrypted hard disk. Best of all would be to get rid of the microSD at all, that means that /boot should also lie onto the 3.5" disk. As I understood from some tutorials on the net so far, I would need GRUB2 therefore. Is this task possible for the ODROID-HC2 and 3.5" external disk ?

[mad_ady]

At least the contents of /media/boot (the first partition) needs to be on SD unencrypted for the box to boot and load kernel. The initramfs can decrypt the rootfs and mount it. There was an article on Odroid Magazine that should still work: https://magazine.odroid.com/article/sec ... tem-linux/

[gnome_shell]

I guess it isn't possible to also have the boot partition in an ecrypted drive because GRUB is needed but GRUB is not availabel on the ODROID-HC2 official latest Ubuntu image?

What bootloader is used on the ODROIC-HC2 and is it capable to decrpyt luks devices ?

The link you posted does only explain how to create a LUKS encrypted disk and auto-mount it on boot. But it does not show how to move the ODROID-HC2 installation to a fully-encrypted-drive. I am interested in how-to move all stuff from the microSD card to the fully-encrypted LUKS partition and build the initrd and all crypt-related stuff. Unless not otherwise possible I would leave the boot partition on the microSD card.

any other useful tutorials for the ODROID-HC2 how to fulfill this task?

[mad_ady]

Ok, perhaps it wasn't the correct guide....
There were people that used dropbear in a initramfs to unlock their rootfs: https://www.google.com/url?sa=t&source= ... FGznK6Xbce

There are ways to have uboot (the default bootloader) start grub instead of booting linux. See here: https://www.google.com/url?sa=t&source= ... vTgnRN79bM

[igorpec]

Hi Igor,

Will this work on Ubuntu image?

No idea. Like I said - I don't deal with this, but we do have support for full disk encryption in the build system. Which means it works to some people for sure, otherwise that would not be added.

For "Ubuntu" images, Hardkernel will tell you how to proceed. If.

Actually I cannot and won't use the Armbian image any more because it failed in several tests I made last week. The armbian image (tested Buster and Bullseye) both already fail the iperf test which shows only 600 MBit/s of the expected 900 MBit/s.

Lower speed is not a failure, but a temporal bug. Since we use virtually unchanged Hardkernel kernel, bug was also present with Hardkernel / was their fault. It was repaired during this week, images were rebuilt, (apt package) update is coming out during this weekend. Doing it faster makes no sense - Hardkernel doesn't support community investments into their business - you choose what you like.

Code: Select all

root@10.0.10.249's password: 
  ___      _           _     _  __  ___   _ _  _   
 / _ \  __| |_ __ ___ (_) __| | \ \/ / | | | || |  
| | | |/ _` | '__/ _ \| |/ _` |  \  /| | | | || |_ 
| |_| | (_| | | | (_) | | (_| |  /  \| |_| |__   _|
 \___/ \__,_|_|  \___/|_|\__,_| /_/\_\\___/   |_|  
                                                   
Welcome to Armbian 21.08.3 Focal with Linux 5.4.151-odroidxu4

System load:   1%           	Up time:       44 min	
Memory usage:  6% of 1.94G  	IP:	       10.0.10.249
CPU temp:      42°C           	Usage of /:    7% of 15G    	

[ General system configuration (beta): armbian-config ]

Last login: Sat Oct  9 09:40:48 2021 from 10.0.10.12
odroidxu4:~:# iperf3 -c 10.0.10.8
Connecting to host 10.0.10.8, port 5201
[  5] local 10.0.10.249 port 38250 connected to 10.0.10.8 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   101 MBytes   849 Mbits/sec    1    455 KBytes       
[  5]   1.00-2.00   sec   105 MBytes   877 Mbits/sec    4    382 KBytes       
[  5]   2.00-3.00   sec   104 MBytes   875 Mbits/sec    0    458 KBytes       
[  5]   3.00-4.00   sec   103 MBytes   867 Mbits/sec    0    523 KBytes       
[  5]   4.00-5.00   sec   104 MBytes   872 Mbits/sec   11    461 KBytes       
[  5]   5.00-6.00   sec   104 MBytes   875 Mbits/sec    0    523 KBytes       
[  5]   6.00-7.00   sec   104 MBytes   873 Mbits/sec    7    397 KBytes       
[  5]   7.00-8.00   sec   105 MBytes   884 Mbits/sec    0    491 KBytes       
[  5]   8.00-9.00   sec   108 MBytes   905 Mbits/sec    0    547 KBytes       
[  5]   9.00-10.00  sec   110 MBytes   924 Mbits/sec    0    547 KBytes  

Telling that Armbian is worse / not acceptable, while not getting anywhere with a stock "Ubuntu" neither is a bit disrespectful, don't' you think? Things you are asking for are not exactly "plug and play Raspberry Pi feature" and if you want that they become, invest some time and money and make them. I or Armbian (probably Hardkernel as well) don't need them. Especially if its expensive to provide. You do.

The throughput is horrible bad.

Armbian is a build system and in case of this particular hardware, we don't maintain kernels where bug was initiated. Perhaps that's why?

As odroid replied, Armbian is not tested and supported for the ODROID-HC2 and only the Ubuntu image is maintained.

Ofc they will not test Armbian. Testing is very expensive feature and almost not present in this cheap consumer world.

They barely test their own creations.

So my question is --> how to Full-Disk-Encryption on the latest Ubuntu image for the ODROID-HC ?

I can give you one more valuable hint - use Armbian https://forum.armbian.com/search/ forum search. It is known that Armbian users were / are using this feature.

[gnome_shell]

@igorpec:

If I interpret your post correctly, you are either a supporter of Armbian or its developers. It was and is not my intention to bash Armbian or any other kind of software or developers. Maybe it came across that way due to my poor English skills. Personally I would prefer Armbian as I am a Debian fan and follower, for this reason I started with Armbian first. It reads from your post as if Armbian and Hardkernel don't have the best relationship and like to point fingers at each other. That's your thing, I won't get involved. What matters to me as a user is that the components I choose work smoothly and at full performance without any issues, nothing more nothing less.

However, I have to admit -even now- that under the current circumstances Armbian is out of the question for use on an ODROID-HC2. I can report this based on my experience and excessive testing. I just tested the new kerel you announced. I installed the latest Armbian Bullseye from 08 Oct 2021 which contains kernel 5.4.151-odroidxu4 #21.08.3 SMP PREEMPT Fri Oct 8 19:52:26 UTC 2021 armv7l GNU/Linux. Now iperf reports correct rates of about 930 MBit/s just like as expected and the Ubuntu image does, but ...

==> Samba throughput horribly fails !

I have a pre-built procedure that I run after a clean install of an image. It installs Samba and uses exactly the same smb.conf as before with the Ubuntu image. Exactly the same hardware, exactly the same samba settings, the same hard disk, everything identical. The actual Armbian Bullseye image shown above delivers rates about max. 40 MB/sec on an unencrypted ext4 partition and plus the rates are fading very high from 10-40 MB/sec! This is unacceptable for a user, whether you like to hear it or not, but it is the case.

The Ubuntu image delivers on the same hardware with exact same installation and setup procedure read and write rates of 100 MB/sec when transferring files via Samba using an unencrypted clean ext4 disk. If I encrypt the disk in a second test with aes-xts-plain64 cipher with 512bit key and sha512 then I get read/write rates of 70 MB/sec. So this is in line with the official Odroid tutorial and field report shown here.

You will have to understand that I, as an ODROID-HC2 buyer and user, will not be satisfied with a worse performance than advertised. In this case, it's a 1 GBit/s network card and 6GB/s SATA port with a hard drive that can read and write at up to 175 MB/sec. If you or anyone else tries to convince me that this is completely normal, then I simply feel fooled. I am not a Linux beginner, on the contrary.

I can give you one more valuable hint - use Armbian https://forum.armbian.com/search/ forum search. It is known that Armbian users were / are using this feature.

Sure. FDE certainly works on all systems if you do it right and have found the way there, but: what use is that if important core components do not work as expected and the data transfer is a quarter of the possible performance? As a user, I will certainly not be satisfied with a maximum of 30% performance.

Furthermore, I find it an impertinence from you that you had written in your post that you would gladly provide support for payment, otherwise I should look where I stay, since it is "only" consumer and experimental landscape. Of course I move in this area and have decided for OpenSource and an ODROID-HC2. For all other more important things there are several 19" devices in the server rack with paid support contracts. You seem to enjoy your flight of fancy with such condescending posts. Just don't fly too high Icarus. You have edited your post in the meantime and removed these lines again. My dear man, you make great advertising for Armbian.I feel sorry for the rest of the developers at Armbian, because they deserve more.

As a Debian fan, I wish the results had gone the other way and I could have used Armbian. However, under the given circumstances of bad performance Armbian is eliminated for use on an ODROID-HC2. The reasons are obviously understandable for everyone. Unfortunately I have to stick with Ubuntu minimal image and continue with that ...

[igorpec]

@igorpec:

If I interpret your post correctly, you are either a supporter of Armbian or its developers. It was and is not my intention to bash Armbian or any other kind of software or developers. Maybe it came across that way due to my poor English skills. Personally I would prefer Armbian as I am a Debian fan and follower

Then first thing it would be best to check what Armbian actually is. Name surely implies that it is "Debian for ARM hardware", "universal OS for ARM hardware", but in fact it is a lot more. Armbian is 1st a build system, which provides different Debian based variants and the main commonalities with Debian are packages relations and the philosophy. Core technology is ours. We actually don't promote Debian based builds, but Ubuntu based. They are free of Canonical, they don't have non-free packages (except one small tool called iotop), ... it is almost the same as Debian package base, just lack of many bugs, which were hunted down by Ubuntu (community). But user land packages and changing wallpapers, what most of distros deal with, are not our focus.

uses exactly the same smb.conf as before with the Ubuntu image. Exactly the same hardware, exactly the same samba settings, the same hard disk, everything identical. The actual Armbian Bullseye

I am not a Linux beginner, on the contrary.

I have to admit -even now- that under the current circumstances Armbian is out of the question for use on an ODROID-HC2. I can report this based on my experience and excessive testing. I just tested the new kerel you announced. I installed the latest Armbian Bullseye

Linux expert clients are most expensive to support - they know everything, they don't accept being wrong and they don't even think about covering the time for the guidance which they reject anyway. I am not saying we started that way, but to understand my reactions.

You took Ubuntu A user space where Samba package version is X and comparing it with Debian B where Samba version is Y ... Also once again - Armbian is a build system that doesn't address Debian user space bugs nor Ubuntu user space bugs (only in a small number without promoting, yes) . We don't have capacity to cover behind 1000 people. But if we receive bugs the way we expect reports are made https://www.armbian.com/bugs things could be fixed by now. Personally I don't use this device, so I would be able to notice anything is wrong. Speed decrease is not a critical bug (its annoying, yes) and can be easily fixed with an update. Sometimes in matter of hours or days after its found. We do have technology, just little motivation to provide service at better levels strictly on our expense.

Furthermore, I find it an impertinence from you that you had written in your post that you would gladly provide support for payment, otherwise I should look where I stay, since it is "only" consumer and experimental landscape. Of course I move in this area and have decided for OpenSource and an ODROID-HC2.

Technically, from hardware interface perspective, those Odroids (and many other single board computers) are not completely open source. Chip vendor has ultimate control. They need close source boot loader. Its as open source as Microsoft Azure Linux VM ... Most people doesn't care.

For all other more important things there are several 19" devices in the server rack with paid support contracts.

When time dealing with single board computers become more important ...

As a Debian fan, I wish the results had gone the other way and I could have used Armbian. However, under the given circumstances of bad performance Armbian is eliminated for use on an ODROID-HC2. The reasons are obviously understandable for everyone. Unfortunately I have to stick with Ubuntu minimal image and continue with that ...

What prevents you to download the code, fix the problem and share it? That is the core of the community projects such as Debian. And that is the common thing we share. A crew of 10-20 people, who are considered as regular contributors or maintainers, can't fix all bugs and certainly can't talk with thousands of "customers" about the problems they have. I was willing to talk, I have tried once, but for serious debugging I have no time. Perhaps someone else will take it over. That's how this works.

[igorpec]

I went and test Samba transfer rate on the same image as doing iperf, which means my prediction was correct. Bug is (probably - will not dig into Debian mess. I can only try to support Armbian, their clients, not random peoples random Linux troubles) in the Samba or related library. Reality is that Debian (Bullseye / new stable), even proclaimed stable, needs at least half a year, a year, to get rid of most obvious troubles ... but that's nothing we can do about.

As from Armbian perspective, this intervention, which wasn't Armbian fault, was a substantial expense and that is the base of my frustration, which you have noticed. This pressure on our non-existing support budget is happening daily.

snapshot.png (29.49 KiB) Viewed 5067 times

[gnome_shell]

@odroid and rest:

is there any tutorial available for full-disk-encryption or at least encrypted root filesystem for the latest Ubuntu image minimal for ODROID-HC2 ? I wanted to try to make this on my own manually but: after installing and wanting to use cryptsetup-initramfs I fail because the ubuntu image on the ODROID-HC2 does not provide the usual initrd? Actually with the ubuntu image I find no way to run "update-initramfs" even after replacing the line

Code: Select all

update_initramfs=no

by

Code: Select all

update_initramfs=yes

in /etc/initramfs-tools/update-initramfs.conf

any clues @odroid ?

[odroid]

We have no experience of using fully encrypted root file system.

BTW, if you needed to update the initramfs, you had to follow this guide.
https://wiki.odroid.com/odroid-xu4/soft ... k_optional

[elatllat]

@gnome_shell

https://resources.infosecinstitute.com/ ... initramfs/

Or another option is just to mount --bind over any folder you want secure.

[gnome_shell]

[...]If you needed to update the initramfs, you had to follow this guide.
https://wiki.odroid.com/odroid-xu4/soft ... k_optional

Hi odroid and thanks for the link. I guess you were referring to these commands here?

Code: Select all

$ sudo cp .config /boot/config-`make kernelrelease`
$ sudo update-initramfs -c -k `make kernelrelease`
$ sudo mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n uInitrd -d /boot/initrd.img-`make kernelrelease` /boot/uInitrd-`make kernelrelease`
$ sudo cp /boot/uInitrd-`make kernelrelease` /media/boot/uInitrd
$ sync

the first command is not possible because I have no .config file, I didn't download and compile the kernel as explained one step before in that mentioned tutorial. That being said I cannot continue with the next command because "update-initramfs" won't find any initrd file under /boot because there is no one by default in the ubuntu minimal image. There is only the uInitrd but update-initramfs doesn't seem to be able to handle this file. Here's an output of my /boot under the Ubuntu minimal image:

# uname -a && lsb_release -a
Linux myhost 5.4.150-233 #1 SMP PREEMPT Tue Oct 5 18:47:06 EDT 2021 armv7l armv7l armv7l GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal

Code: Select all

root@myhost:/boot# ls -lh
total 16880
drwxr-xr-x  3 root root    16384 Jan  1  1970 ./
drwxr-xr-x 21 root root     4096 Okt 23 15:24 ../
-rwxr-xr-x  1 root root     2342 Okt 22 10:20 boot.ini*
-rwxr-xr-x  1 root root     7156 Aug  4  2020 config.ini*
-rwxr-xr-x  1 root root    81864 Sep 28 21:36 exynos5422-odroidhc1.dtb*
-rwxr-xr-x  1 root root    87965 Sep 28 21:36 exynos5422-odroidxu3.dtb*
-rwxr-xr-x  1 root root    87474 Sep 28 21:36 exynos5422-odroidxu3-lite.dtb*
-rwxr-xr-x  1 root root    87141 Sep 28 21:36 exynos5422-odroidxu4.dtb*
-rwxr-xr-x  1 root root    63636 Aug  4  2020 exynos5422-odroidxu4-kvm.dtb*
drwxr-xr-x  2 root root     2048 Sep 28 21:36 overlays/
-rwxr-xr-x  1 root root 10322709 Sep 28 21:36 uInitrd*
-rwxr-xr-x  1 root root  6512744 Sep 28 21:36 zImage*

can you explain to me, how to update my existing initramfs here, please? thanks so much for your patience and assistance.

[elatllat]

@gnome_shell

Those steps assume you are building a kernel, if you are not, you need to look up how to get all the bits from the pre-built one.

zcat /proc/config.gz > .config

Might be a start.

[gnome_shell]

thanks for that information. Meanwhile I've found out that /boot (inside root filesystem) contains the initrd files which could be used for upgrading? How do I find out what command/script is being triggered when (re-)installing the package linux-image-current-odroidxu4 ? I did out accidently that the installation of this package triggers an update-initramfs which works fine and also as result converts to the wanted u-boot format. It would be nice to isolate this triggering process and use it as a wrapper for my future update-initramfs events.

[elatllat]

I just disabled the package and update from kernel.org but DKMS is likely the right tool for what you want

https://wiki.archlinux.org/title/Dynami ... le_Support

ubuntu has
/usr/share/apport/package-hooks/

[mad_ady]

See also /etc/kernel.d/* for scripts that run post a kernel installation.

[gnome_shell]

We don't offer a image with full disk encryption enabled by default for security reasons.
If you really need that, you must be aware how to config/administer this.

As for the initramfs...

1. Create a new initramfs

sudo update-initramfs -c -k `uname -r`

2. Add the u-boot header to the new initramfs

sudo mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n uInitrd -d /boot/initrd.img-`uname -r` /boot/uInitrd-`uname -r`

3. copy the new uinitrd to the boot partition, replacing the old one.

sudo cp /boot/uInitrd-`uname -r` /media/boot/uInitrd

Step 1, is regular linux stuff, nothing odroid specific.
Step 2, is u-boot specific, it just adds a 72byte header on top of the initramfs to identify it to the bootloader.
Step 3, is odroid-specific just where files should be.

No ODROID boards (with the exception of ODROID-H2) uses Grub, they all use u-boot.
See: https://www.denx.de/wiki/U-Boot
You can have access to the bootloader by using the USB-Serial cable we sell.
Also, the boot partition (kernel image, dtb and initramfs) can't be encrypted and u-boot is unable to handle it.

As mad_ady noted, https://magazine.odroid.com/article/sec ... tem-linux/ is pretty much what we support.

[gnome_shell]

No ODROID boards (with the exception of ODROID-H2) uses Grub, they all use u-boot.
See: https://www.denx.de/wiki/U-Boot
You can have access to the bootloader by using the USB-Serial cable we sell.
Also, the boot partition (kernel image, dtb and initramfs) can't be encrypted and u-boot is unable to handle it.

Even not by using grub-uboot package for chainloading u-boot --> grub --> linux? (see here) The goal would be to have the boot partition in GRUB version 1 (which supports encryption) and the rest of GRUB in version 2 (as usual).

EDIT: After some thoughts I guess even in that constellation it would be useless. The goal was to have the whole system encrypted so noone can change boot files and loaders. But in that case u-boot still is existent and needs to be unencrypted. The system would be vulnerable to injects through u-boot. Ok, I guess this question is answered. However, thanks