1 (edited by rian 2015-01-13 17:34:15)

Topic: Encrypted root disk

Just got a SATA disk to use with my Novena but I don't like having disks with blatantly unencrypted data on them. So I made a couple of changes to novena-image.sh to bootstrap my SATA disk with encryption.

I was shooting for no required changes to stock kernel and u-boot but I hit a snag. In my testing it looks like the aes-arm-bs module contains a busted XTS implementation. This isn't a problem if you aren't using XTS disk encryption, but the other modes are a bit less secure. The quick fix for me was to recompile a kernel with the follow config changes:

CONFIG_CRYPTO_AES_ARM_BS=n
CONFIG_CRYPTO_XTS=m

This is only temporary, I'm currently working on a fix to the aes-arm-bs module to restore the optimized behavior.

Re: Encrypted root disk

I'll update our defconfig to include those settings (along with some other enhancements, like bridging and CDC-ACM support).

Re: Encrypted root disk

Hi rian

I was trying to use your script. It seems to work, but as soon as I'm trying to boot to the new system, the boot process is stuck after

random: nonblocking pool is initialized

Further up is the more relevant line:

Waiting for root device /dev/mapper/crypt-root...

Could you point me to what I have to do to actually get asked for a password?

En-/Decryption from the SD-Card works, I installed kernel 3.19 from the novena-linux repository on github on my novena desktop and also added the corresponding .deb-packet to the wrapper script with a -a option. So I guess, I only have to specify somewhere that I need to enter a password.

Any help would be highly appreciated.

jogi

4 (edited by rian 2015-04-09 00:06:21)

Re: Encrypted root disk

Hi Jogi,

It should ask you for your password shortly after the kernel passes control to init via the debian initramfs boot system.

In this case the initramfs isn't activating. I'm 99% sure it's because there is a small typo in my script. So sorry about that! I must have avoided this error because my uEnv.txt was set manually.

To fix, you'll have to boot your novena in recovery mode (during reset holding the right button on the board below the Debug Serial UART pins). This tells the uboot boot loader to load the recovery kernel and boot from the SD card regardless of the EEPROM setting. Once there, you can either run the script again (which will take a while) or you can manually patch the /boot/uEnv.txt file on your SD-card (pulled from script):

#!/bin/sh
uInitrd_size=$(wc -c "/boot/uInitrd")
initrd_addr_r=$(printf "0x%x" $(((0x11ff0000 - uInitrd_size) & 0xffff0000)))
echo -en 'earlyhook=if test "$rootdev" = "PARTUUID=4e6f7653-03"; then setenv rootdev /dev/mapper/crypt-root ; fi\0finalhook=if test "$rootdev" = "/dev/mapper/crypt-root"; then setenv initrd_addr_r '${initrd_addr_r}' ; fatload ${bootsrc} ${bootdev} ${initrd_addr_r} uInitrd ; fi' > "/boot/uEnv.txt"

Double check /boot/uEnv.txt to make sure it looks sane. Once you're happy, then reboot the system normally. If I was correct about initrd not being loaded, then you should get a password prompt. Yeah!

Rian

Re: Encrypted root disk

Hi Rian

Thanks for taking time. I got into recovery mode and triede different kernels and other stuff before I made the first post here, so that wasn't an issue. However, since somewhen even recovery wouldn't work anymore, I decided to start from scratch. So  I took the Image from the wiki, put it on the SD-Card and just took the following steps:

  • Set up Wifi

  • apt-get update && apt-get install cryptsetup apt-cacher-ng u-boot-tools

  • Cloned your fork of the repo and got the .debs with apt-get download

  • ./encrypted-sata-install.sh /dev/sda

It runs through without error. When I look at the output in Detail, I see the following portion, where there is a division by 0

+ mkimage -A arm -O linux -T ramdisk -n 'Initial Ram Disk' -d /tmp/newroot.3413/
boot/initrd.img-3.17.0-rc5-00217-gfd79638 /tmp/newroot.3413/boot/uInitrd
Image Name:   Initial Ram Disk
Created:      Thu Apr  9 12:13:51 2015
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    5086141 Bytes = 4966.93 kB = 4.85 MB
Load Address: 00000000
Entry Point:  00000000
+ '[' -e /tmp/newroot.3413/boot/uEnv.txt ']'
++ wc -c /tmp/newroot.3413/boot/uInitrd
+ uInitrd_size='5086205 /tmp/newroot.3413/boot/uInitrd'
./novena-image.sh: line 390: 5086205 /tmp/newroot.3413/boot/uInitrd: division by 0 (error token is "tmp/newroot.3413/boot/uInitrd")
+ initrd_addr_r=
+ echo -en 'earlyhook=if test "$rootdev" = "PARTUUID=4e6f7653-03"; then setenv rootdev /dev/mapper/crypt-root ; fi\0finalhook=if test "$rootdev" = "/dev/mapper/crypt-root"; then setenv initrd_addr_r  ; fatload ${bootsrc} ${bootdev} ${initrd_addr_r} uInitrd ; fi'
+ remove_ssh_keys /tmp/newroot.3413

Nevertheless, in the end, I got:

Everything was a success. Don't forget to run: 

And so on.

The division by 0 took probably place in this line:

uInitrd_size=$(wc -c "/boot/uInitrd")

If you look at the following output, it becomes clear, that there is an additional string in this variable:

jogi@novena-partner-veteran:~$ uInitrd_size=$(wc -c "/boot/uInitrd")
jogi@novena-partner-veteran:~$ echo $uInitrd_size 
5086205 /boot/uInitrd

Try instead:

jogi@novena-partner-veteran:~$ uInitrd_size=$(wc -c "/boot/uInitrd" | cut -f 1 -d ' ')
jogi@novena-partner-veteran:~$ echo $uInitrd_size 
5086205

If I change the script to

#!/bin/sh
uInitrd_size=$(wc -c "/boot/uInitrd" | cut -f 1 -d ' ')
initrd_addr_r=$(printf "0x%x" $(((0x11ff0000 - uInitrd_size) & 0xffff0000)))
echo -en 'earlyhook=if test "$rootdev" = "PARTUUID=4e6f7653-03"; then setenv rootdev /dev/mapper/crypt-root ; fi\0finalhook=if test "$rootdev" = "/dev/mapper/crypt-root"; then setenv initrd_addr_r '${initrd_addr_r}' ; fatload ${bootsrc} ${bootdev} ${initrd_addr_r} uInitrd ; fi' > "/boot/uEnv.txt"

It doesn't give me an error, but because of the \0 in there, my uEnv.txt looks only like this after running the script:

-en earlyhook=if test "$rootdev" = "PARTUUID=4e6f7653-03"; then setenv rootdev /dev/mapper/crypt-root ; fi

In the full install-script, the \0 gets converted to an ^@ and then comes the finalhook, so tonight I will try to run the full install once again with my modification. But I don't get the sense behind this null-character in there...

Jogi

Re: Encrypted root disk

Well that -en certainly shouldn't have made it into the beginning of that line in uEnv.txt, as it's a parameter to the echo command. Have you misplaced a quote on that echo line or something?

The \0 should probably be a \n.

Re: Encrypted root disk

Got it, changed #!/bin/sh to #!/bin/bash.

Now, regardless of \0 or \n, I get asked

Please unlock disk /dev/sda3(crypt-root): Cannot initialize device-mapper. Is dm_mod kernel module loaded?

After that, I can enter a password (No characters get shown) and after I hit enter, I get the result

cryptsetup: cryptsetup failed, bad password or options?

Of course, without the dm_mod module, it won't work. (The password is correct, i have 1234 for testing purposes at the moment)

Also interesting is the line before:

modprobe: can't change directory to '3.17.0-rc5-00205-g3b9fb62': No such file or directory

So I guess, I need to provide a path to the module. And as soon as this works, it should theoretically boot, right?

contents of /boot:

jogi@novena-partner-veteran:~$ ls -la /boot/
total 17402
drwxr-xr-x  2 root root   16384 Jan  1  1970 .
drwxr-xr-x 21 root root    4096 Nov 14 14:29 ..
-rwxr-xr-x  1 root root 5086141 Apr  9 10:13 initrd.img-3.17.0-rc5-00217-gfd79638
-rwxr-xr-x  1 root root   39839 Apr  9 10:13 novena.dtb
-rwxr-xr-x  1 root root   39835 Nov 14 20:29 novena.recovery.dtb
-rwxr-xr-x  1 root root  304876 Apr  9 10:12 u-boot.img
-rwxr-xr-x  1 root root   35840 Apr  9 10:12 u-boot.spl
-rwxr-xr-x  1 root root     258 Apr  9 15:30 uEnv.txt
-rwxr-xr-x  1 root root 5086205 Apr  9 10:13 uInitrd
-rwxr-xr-x  1 root root 3597296 Apr  9 10:13 zimage
-rwxr-xr-x  1 root root 3598728 Nov 14 20:29 zImage.recovery

contents of uEnv.txt:

earlyhook=if test "$rootdev" = "PARTUUID=4e6f7653-03"; then setenv rootdev /dev/mapper/crypt-root ; fi^@finalhook=if test "$rootdev" = "/dev/mapper/crypt-root"; then setenv initrd_addr_r 0x11b10000 ; fatload ${bootsrc} ${bootdev} ${initrd_addr_r} uInitrd ; fi

Re: Encrypted root disk

jogi wrote:

Also interesting is the line before:

modprobe: can't change directory to '3.17.0-rc5-00205-g3b9fb62': No such file or directory

So I guess, I need to provide a path to the module. And as soon as this works, it should theoretically boot, right?

You're not trying to load the encryption module from the encrypted filesystem, are you? It's in the initrd.img?

Re: Encrypted root disk

First of all: I got it to run. Thanks to all people that have helped me.

First I tried to install a different kernel, played with update-initramfs and mkimage and at some point, I got to a shell in the initramfs. Since I couldn't figure out how to decrypt the root partition from there, I compiled a new kernel with the cryptsetup support directly compiled into it, so no module to load and that worked. However, now that I have that, I'm starting from scratch (i.e. a recovery-image), and I will try to Document each step and streamline the whole thing.

For that matter: Does anybody have a recommendation for me to read about the boot process? The whole thing was a bit puzzling together the relations between the different images for me: uImage, zImage, initramfs etc. I probably missed some things, like which module is where at which point in time.

Re: Encrypted root disk

As Promised, here comes my complete Documentation of the steps taken. I guess, part of my earlier problems was, that some packets which were installed were not available in the repo (newer kernel version in image than available in repo). After adding my fix to the script and installing (downgrading) to a kernel which was available, it worked out of the box. (I also removed some .debs from the wrapper so it doesn't need to download so much)

@Rian: I created a pull-Request on Github with the change. Feel free too use it or refuse it. I really appreciated your encryption wrapper script as a starting point.

Documentation on the encryption of an SSD in the novena (At least, how it worked for me)

Starting Point:

  • Novena

  • Empty SD-Card

First: Flash image according to the main page of the wiki

Boot up novena

As root, execute:

apt-get update
apt-get upgrade
apt-get install debootstrap cryptsetup apt-cacher-ng u-boot-tools
apt-get install linux-image-novena=1.14-rc1 linux-firmware-image-novena=1.14-r1
reboot
git clone [url]https://github.com/jogi91/novena-image.git[/url]
cd novena-image
apt-get download u-boot-novena irqbalance-imx novena-eeprom kosagi-repo novena-firstrun=1.4-r1

(Installed version of firstrun newer than in repo, specify version so it gets found)

./encrypted-sata-install /dev/sda

Re: Encrypted root disk

Could the encrypted-sata-install script get pulled into upstream, maybe?  Would be useful

Re: Encrypted root disk

so i successfully encrypted the root disk with the help from this page.  But, err, I am using a bluetooth keyboard.  Has anyone gotten a bluetooth device working at boot yet? Theres not a lot of info around, unless I want to use grub2.

13 (edited by chris4795 2015-07-19 05:50:04)

Re: Encrypted root disk

veleiro,

I don't think the bluetooth stack is initialized until after the root disk is encrypted. I have a bluetooth adaptor that does not need any closed source drivers, and I cannot get the bluetooth keyboard to work. On my desktop that is root encrypted, I see the bluetooth initialize very late in the boot process. I also think the pairing device files are not in the /boot section, so even if bluetooth was initialized, it would have no idea what to connect to.

If you want a wireless keyboard with encrypted rootdisk, think these are your options:
- Get a wireless bridge device (I think they would just appear to be a USB keyboard to Linux)
- Get a bluetooth keyboard that also suports USB (the Lenovo Bluetooth keyboard does not supprt this, the USB is only for charging as far as I can tell)
- Get a USB keyboard in addition to the wireless keyboard

14 (edited by veleiro 2015-07-21 11:08:22)

Re: Encrypted root disk

Im not familiar with uboot, but I thought ive seen ways to initialize BT in grub so that you can use BT devices there.  I also have a bluetooth adaptor like yours.

Is it a dumb idea to use grub with uboot?

15 (edited by freehub 2015-08-23 15:36:40)

Re: Encrypted root disk

jogi wrote:

As Promised, here comes my complete Documentation of the steps taken. I guess, part of my earlier problems was, that some packets which were installed were not available in the repo (newer kernel version in image than available in repo). After adding my fix to the script and installing (downgrading) to a kernel which was available, it worked out of the box. (I also removed some .debs from the wrapper so it doesn't need to download so much)

@Rian: I created a pull-Request on Github with the change. Feel free too use it or refuse it. I really appreciated your encryption wrapper script as a starting point.

Documentation on the encryption of an SSD in the novena (At least, how it worked for me)

Starting Point:

  • Novena

  • Empty SD-Card

First: Flash image according to the main page of the wiki

Boot up novena

As root, execute:

apt-get update
apt-get upgrade
apt-get install debootstrap cryptsetup apt-cacher-ng u-boot-tools
apt-get install linux-image-novena=1.14-rc1 linux-firmware-image-novena=1.14-r1
reboot
git clone [url]https://github.com/jogi91/novena-image.git[/url]
cd novena-image
apt-get download u-boot-novena irqbalance-imx novena-eeprom kosagi-repo novena-firstrun=1.4-r1

(Installed version of firstrun newer than in repo, specify version so it gets found)

./encrypted-sata-install /dev/sda

Thank you for these instructions. During the last weeks the specified packages have been deleted from the repo seemingly:

jogi wrote:

linux-image-novena=1.14-rc1 linux-firmware-image-novena=1.14-r1

Upgrading to the newest defaults results in a system that can not successfully boot into recovery mode for me. The screen turns black after displaying some lines and the backlight turns off shortly after.

My next step would have been the use of a serial console. While technically possible, this course of action can not be persued by me for other reasons currently.

The problem's cause might just be the versions of the packages in use. Maybe a kernel upgrade is necessary before reboot? Maybe the issue is related to the 'Screen occasionally fails to come on when booting' thread in the Software forums?

jogi wrote:

(Installed version of firstrun newer than in repo, specify version so it gets found)

I was not entirely sure whether the installed version was newer or older than default. My guess would be newer though.

In any case installing packages of a certain version might resolve the issue. If anyone got information on how to set up an encrypted root disk currently it would be most welcome.

Regarding the github repo: rian seemingly used jogi's pull request.

Re: Encrypted root disk

I finished creating a Debian installer for Novena now, which supports encrypted root disks with LUKS:
https://github.com/thesourcerer8/novena … -installer

Thanks for all the giants on whose shoulders I was able to stand!

17 (edited by veleiro 2015-09-03 13:02:58)

Re: Encrypted root disk

Sourcerer:

The installer is awesome, but after I install (using the image you provided), I get "cannot initialize device mapper, is dm_mod kernel loaded?" I used guided use full disk (luks + enc)

before the boot mmc boot was enabled on the eeprom, not sata, and it looked like it put /boot on the ssd.

18 (edited by freehub 2015-09-04 00:42:12)

Re: Encrypted root disk

Definitely some progress, since Sourcerer's script allows me to start the installation-process now.

I have been using the standard Novena Micro-SD image with enlarged boot partition. I did not get as far as veleiro reported, though. The installation-script stopped once the passphrase had been entered. A message-box was displayed, stating “An error had occurred while configuring encrypted volumes. The configuration has been aborted.” The logs revealed kernel entropies with less than 1024 bits in several attempts to set up encrypted LVM root and /home partitions. “No key available with this passphrase.”. The “guided” option was chosen, too.

veleiro: I have been using LUKS on my e-waste recycling notebook. In your case the kernel modules might not have been added. Maybe running the hook script mentioned on https://github.com/thesourcerer8/novena … -installer manually could resolve this? Generally speaking a volume “name” with partition “rootname” on device /dev/sdx can be accessed by (sudo when needed):

fdisk -l
(to determine the device sdx)

cryptsetup luksOpen /dev/sdx name
vgscan
lvscan
vgchange -ay
mkdir /mnt/Vol
mount /dev/name/rootname /mnt/Vol
(access should be possible now)

umount /dev/name/rootname
vgchange -an
cryptsetup luksClose name
(to unmount partition and close the volume)

I do not have the time to do any testing currently, unfortunately. It seems that an encrypted root install is within reach, though. Thank you for the script Sourcerer. It was encouraging to hear your feedback, too, veleiro.

19 (edited by dileepvr 2015-09-05 00:57:14)

Re: Encrypted root disk

Hi all,

Regarding encrypted Swap, I'd recommend moving away from generating a random passphrase at every boot and instead follow  Madducks advice: http://madduck.net/docs/cryptdisk/.

And be sure to add

resume=/dev/mapper/crypt-swap

to the kernel command line (possibly through uEnv.txt). You will need "noauto,nofail" options for the swap inside fstab and crypttab to do this, because systemd still has issues. Then, you can run swapon through a systemd service file after cryptsetup has done its thing during boot. I have gotten this to work with novena-linux 3.19 kernel.

Re: Encrypted root disk

Yes, I thought I already had it running properly, I was able to boot correctly, enter the passphrase and use the system, ... but now it seems to fail with those modul loading problems and similar for me too. I verified the modules, and they are there in the right place, but mysteriously they can´t be loaded.
I hope I will have some timeslots soon for testing and finishing it.

Regarding /boot: Yes, my concept is to have /boot on the SSD, since the files that are generated by Debian in /boot can´t be used for booting directly and have to be converted, so my scripts mount, generate and copy the needed files to the FAT partition on the MicroSD card.

21 (edited by freehub 2015-10-29 06:49:34)

Re: Encrypted root disk

Sourcerer wrote:

Yes, I thought I already had it running properly, I was able to boot correctly, enter the passphrase and use the system, ... but now it seems to fail with those modul loading problems and similar for me too. I verified the modules, and they are there in the right place, but mysteriously they can´t be loaded.
I hope I will have some timeslots soon for testing and finishing it.

Regarding /boot: Yes, my concept is to have /boot on the SSD, since the files that are generated by Debian in /boot can´t be used for booting directly and have to be converted, so my scripts mount, generate and copy the needed files to the FAT partition on the MicroSD card.

Since there had been activity on your github script, I have given it another try. The logs revealed kernel entropies with less than 1024 bits in an attempt to set up encrypted LVM root and /home partitions, again. “No key available with this passphrase.”. The “guided” option was chosen as well this time.

Have I implemented the script incorrectly? Or is it currently unfinished?

On another note, has anyone managed to set up an encrypted root disk on the Novena platform recently? If so, it would be great if you could share the method. Any hint is welcome, too.

Re: Encrypted root disk

Yes, the script finally worked for me, and I also heard positive reports from other users.
But in the mean time the repositories have changed, so I think a new version is necessary now.
How and where did you got the kernel entropy with 1024 bits? Did it block the installation?
I have only tried a guided full-disk encryption, I didn´t tried seperate /home partitions for the installation yet.
Have you tried the image I am providing? The script might depend on things that might not be present on your machine, but it should (have) work(ed) correctly.
I have used my script successfully which resulted in the image I am also providing to install my Novena. I have designated my Novena to be a production system for me, so I can´t test the installation on it anymore at the moment.
My plan is to buy a new SSD in the next few days so that I can continue testing and improving the installer again.

Re: Encrypted root disk

freehub wrote:
Sourcerer wrote:

Yes, I thought I already had it running properly, I was able to boot correctly, enter the passphrase and use the system, ... but now it seems to fail with those modul loading problems and similar for me too. I verified the modules, and they are there in the right place, but mysteriously they can´t be loaded.
I hope I will have some timeslots soon for testing and finishing it.

Regarding /boot: Yes, my concept is to have /boot on the SSD, since the files that are generated by Debian in /boot can´t be used for booting directly and have to be converted, so my scripts mount, generate and copy the needed files to the FAT partition on the MicroSD card.

Since there had been activity on your github script, I have given it another try. The logs revealed kernel entropies with less than 1024 bits in an attempt to set up encrypted LVM root and /home partitions, again. “No key available with this passphrase.”. The “guided” option was chosen as well this time.

Have I implemented the script incorrectly? Or is it currently unfinished?

On another note, has anyone managed to set up an encrypted root disk on the Novena platform recently? If so, it would be great if you could share the method. Any hint is welcome, too.

Freehub,

I did it on Saturday successfully. I used the image provided to do the installation.

http://www.kosagi.com/forums/viewtopic.php?id=59

I did it with the guided partition, and I put my notes on things I had to do to get a working installation in this thread.

Re: Encrypted root disk

@Sourcerer: Thank you for your effort with the encrypted setup. It is much appreciated. If you change the SSD on a regular basis, some kind of clip-on solution or rack might be handy.

There is a new repository indeed, see http://www.kosagi.com/forums/viewtopic. … 2391#p2391. A quick check on your makeimage.sh script showed, that at least the downloaded keys still seem to be valid. They have been properly upgraded at the pulled locations.

I will start another attempt when my schedule permits. In case of errors I am planning on taking detailed notes in order to answer your questions. Partition scheme, text- versus x-mode and locale were also among my thoughts regarding the cause of the problem.

At least I got feedback and know your script is working.

@chris4795: Same goes for you, thank you so much for all of your feedback.

I am understanding you along the lines that you have used Sourcerer's out-of-the-box MicroSD card image. Then have chosen the guided partition option. It seems to me, that all the other steps were taken post install in order to improve system performance. Also the fstab modification perhaps, in order to update properly? Have you used a single volume instead of a separate instance for /home?

My other projects are making good progress right now, so chances are I will be able to post a report till the end of this week.

25 (edited by chris4795 2015-11-11 07:18:29)

Re: Encrypted root disk

Hey Freehub!

Yes, I used the out of the box microSD image.

When I did the guided partition, I did not do a separate /home folder, but I see no reason that it would not work. Just make sure you do the guided partitioning instead of doing it manually. That is where I messed up.

The X modifications were in order to get X started. When I did not do it, I got a "no screen detected" error.

The fstab modification was to make it look like my original fstab (from the factory), but sourcerer is saying that is not needed to update the partitions. I made the /boot modification before I did any updating, and it worked for me.

I hope that helps!