Full encrypted disk support on coreboot/libreboot BIOS machines

[tlaurion]

Qubes OS version (e.g., R3.1):

R3.0, R3.1

Affected TemplateVMs (e.g., fedora-23, if applicable):

qubes-installer iso

---

Expected behavior:

Partition type requirements should be loosened up on systems having coreboot/libreboot bios replacement, since that bios can open luks container itself and load initrd and kernel inside, permitting full disk encryption.

Fonctional patchwork was provided here against Qubes 3.1

Passphrase will be asked twice. Once by coreboot/libreboot, and a second time when booting the kernel until a keyfile is introduced in the initrd like here

Actual behavior:

The installer requires /boot to be unencrypted even though coreboot/libreboot bios replacement is present.

Steps to reproduce the behavior:

1-Boot from Qubes 3.1 without provided patch
2-Create a shell script with the following content and execute it consciously from shell:

# X200 script to be executed inside Qubes installation shell before doing anything else!
# BEWARE! This script erases /dev/sda content and creates luks container and default required partitions
sed -e 's/\s*\([\+0-9a-zA-Z]*\).*/\1/' << EOF | fdisk /dev/sda
  o # Create DOS partition table
  n # new partition
  p # primary partition
  1 # partition number 1
    # default - start at beginning of disk 
    # default, extend partition to end of disk
  w # write the partition table
  q # and we're done
EOF
#luks container creation
cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash whirlpool --use-random --verify-passphrase luksFormat /dev/sda1
cryptsetup luksOpen /dev/sda1 lvm
pvcreate /dev/mapper/lvm
vgcreate matrix /dev/mapper/lvm
lvcreate -L 8G matrix -n swapvol 
lvcreate -l +100%FREE matrix -n rootvol
mkswap /dev/mapper/matrix-swapvol
mkfs.ext4 /dev/mapper/matrix-rootvol
lvchange -an /dev/matrix/*
cryptsetup luksClose lvm

2-Continue installation on the previously created luks container. It will fail saying its impossible on an encrypted disk. On a libreboot/coreboot bios replaced machine booting a iso created with the provided patch, the Installer would continue, permitting full encrypted disk support.

General notes:

---

Related issues:

If your coreboot/libreboot laptop can't boot from usb drive/dvd drive, add seabios to your coreboot/libreboot bios replacement image with the following script and reflash.
Add seabios to libreboot images

[tlaurion]

Anyone could improve Fonctional patchwork was provided here against Qubes 3.1 so that it could be merged to 3.2 torward fedora-23 ?

@marmarek ?

[tlaurion]

Anyone could improve Fonctional patchwork was provided here against Qubes 3.1 so that it could be merged to 3.2 torward fedora-23 ?

@marmarek ?

[marmarek]

Yes, I have it already in my local testing repo. There were some modifications needed, for example add dmidecode to the installer image as it wasn't there...

[marmarek]

Yes, I have it already in my local testing repo. There were some modifications needed, for example add dmidecode to the installer image as it wasn't there...

[tlaurion]

Dare to branch it online and give me an url so i can build qubes-installer from it and rebuild iso from it? I would be happy to test and report. Thanks, @marmarek .

[tlaurion]

Dare to branch it online and give me an url so i can build qubes-installer from it and rebuild iso from it? I would be happy to test and report. Thanks, @marmarek .

[marmarek]

@tlaurion sure, r32-coreboot branch in https://github.com/marmarek/qubes-installer-qubes-os.

[marmarek]

@tlaurion sure, r32-coreboot branch in https://github.com/marmarek/qubes-installer-qubes-os.

[marmarek]

Just verified it doesn't break non-coreboot installation.

[marmarek]

Just verified it doesn't break non-coreboot installation.

[tlaurion]

I get "/boot file system cannot be on encrypted block device"

Which could be triggered from stage or stage2.
Will try to compare patchwork and update.

[tlaurion]

I get "/boot file system cannot be on encrypted block device"

Which could be triggered from stage or stage2.
Will try to compare patchwork and update.

[marmarek]

Check which bootloader class is used on coreboot system. I've assumed it is GRUB2 (which is default for x86 in non-EFI mode).

[marmarek]

Check which bootloader class is used on coreboot system. I've assumed it is GRUB2 (which is default for x86 in non-EFI mode).

[tlaurion]

That's the problem, if I understand well (quick test this morning).

The GRUB2 bootloader won't be visible from anaconda perspective, since it is in the firmware and non-accessible from the installer. We need to assume it is there and deploy grub2 files, but without actually installing a bootloader ourselves.

But yes, it is GRUB2, and would require GRUB2 second payload from coreboot if bootloader was Seabios or any other.

Can you pinpoint where that bootloader assumption was made (which is different to my approach?)

[tlaurion]

That's the problem, if I understand well (quick test this morning).

The GRUB2 bootloader won't be visible from anaconda perspective, since it is in the firmware and non-accessible from the installer. We need to assume it is there and deploy grub2 files, but without actually installing a bootloader ourselves.

But yes, it is GRUB2, and would require GRUB2 second payload from coreboot if bootloader was Seabios or any other.

Can you pinpoint where that bootloader assumption was made (which is different to my approach?)

[marmarek]

The GRUB2 bootloader won't be visible from anaconda perspective,

It doesn't matter, since the patch set skip_bootloader = True. The only required thing it to stop anaconda from complaining about partition layout.

Can you pinpoint where that bootloader assumption was made (which is different to my approach?)

It's at the end of bootloader.py: https://github.com/marmarek/qubes-installer-qubes-os/blob/cb1dda1897b49d311f05c762d28888bd6506c935/anaconda/pyanaconda/bootloader.py#L2386-L2397

If coreboot system could be detected as separate platform, that would be even better - it would allow plugging some minimal class with no requirements on partition layout at all. Or with requirements specific to grub2 bundled with coreboot.

[marmarek]

The GRUB2 bootloader won't be visible from anaconda perspective,

It doesn't matter, since the patch set skip_bootloader = True. The only required thing it to stop anaconda from complaining about partition layout.

Can you pinpoint where that bootloader assumption was made (which is different to my approach?)

It's at the end of bootloader.py: https://github.com/marmarek/qubes-installer-qubes-os/blob/cb1dda1897b49d311f05c762d28888bd6506c935/anaconda/pyanaconda/bootloader.py#L2386-L2397

If coreboot system could be detected as separate platform, that would be even better - it would allow plugging some minimal class with no requirements on partition layout at all. Or with requirements specific to grub2 bundled with coreboot.

[tlaurion]

It still currently complains about partition scheme even though "skip_booloader = True" is explicited, which is why i'm asking :)

I will try to check differences betweenpatches tonight, but if you have any other insight about why current r32-coreboot branch says "/boot file system cannot be on encrypted block device", please advise.

I am not aware of any other coreboot platform differences.

[tlaurion]

It still currently complains about partition scheme even though "skip_booloader = True" is explicited, which is why i'm asking :)

I will try to check differences betweenpatches tonight, but if you have any other insight about why current r32-coreboot branch says "/boot file system cannot be on encrypted block device", please advise.

I am not aware of any other coreboot platform differences.

[marmarek]

The skip_booloader = True is evaluated after validation of partition layout, somehow independently.
Check where "file system cannot be on encrypted block device" message is logged. Theoretically all those places checks for encryption_support and it should be set to True when coreboot is detected, but maybe for some reason it isn't (for example different bootloader class is used, or dmidecode output doesn't exactly match).

[marmarek]

The skip_booloader = True is evaluated after validation of partition layout, somehow independently.
Check where "file system cannot be on encrypted block device" message is logged. Theoretically all those places checks for encryption_support and it should be set to True when coreboot is detected, but maybe for some reason it isn't (for example different bootloader class is used, or dmidecode output doesn't exactly match).

[tlaurion]

Hmmm.

# grep "dmidecode -s bios-vendor returns coreboot"  /tmp/anaconda.log
# dmidecode -s bios-vendor
coreboot
# grep coreboot /tmp/anaconda.log

It seems that this complete block is never executed. Any idea why?

Some additional information:

# grep platform  /tmp/anaconda.log
[...] bootloader GRUB2 on X86 platform
# grep encrypt /tmp/anaconda.log
[...] updated device_container_encrypted to True
[...] ERR anaconda: /boot file system cannot be on an encrypted block device.
# grep stage2 /tmp/anaconda.log
[...] is_valid_stage2_device(matrix-rootvol) returning False

Thanks @marmarek .

[tlaurion]

Hmmm.

# grep "dmidecode -s bios-vendor returns coreboot"  /tmp/anaconda.log
# dmidecode -s bios-vendor
coreboot
# grep coreboot /tmp/anaconda.log

It seems that this complete block is never executed. Any idea why?

Some additional information:

# grep platform  /tmp/anaconda.log
[...] bootloader GRUB2 on X86 platform
# grep encrypt /tmp/anaconda.log
[...] updated device_container_encrypted to True
[...] ERR anaconda: /boot file system cannot be on an encrypted block device.
# grep stage2 /tmp/anaconda.log
[...] is_valid_stage2_device(matrix-rootvol) returning False

Thanks @marmarek .

[marmarek]

It seems that this complete block is never executed. Any idea why?

Maybe there are some non-printable characters? Check dmidecode -s bios-vendor | xxd.
Or simply change that check to "coreboot" in subprocess.check_output(...)

[marmarek]

It seems that this complete block is never executed. Any idea why?

Maybe there are some non-printable characters? Check dmidecode -s bios-vendor | xxd.
Or simply change that check to "coreboot" in subprocess.check_output(...)

[tlaurion]

string ends by 0a which is line feed and checked against:
63 6f 72 65 62 6f 6f 74 0d 0a coreboot

That worked in precedent patchwork.

Any other hint?

[tlaurion]

string ends by 0a which is line feed and checked against:
63 6f 72 65 62 6f 6f 74 0d 0a coreboot

That worked in precedent patchwork.

Any other hint?

[marmarek]

No, it ends with "0d 0a", which is windows EOL...

[marmarek]

No, it ends with "0d 0a", which is windows EOL...

[tlaurion]

Oupsi. Ok I read the doc, and normally those characters are ignored by python so I will ignore them myself (newline and carriage return), as per your prior recommendation.

I'm mesmerized that that part worked in the patch provided before but wouldn't now, but will try still.

FYI: Here is an example of full dmidecode output on a coreboot system.

[tlaurion]

Oupsi. Ok I read the doc, and normally those characters are ignored by python so I will ignore them myself (newline and carriage return), as per your prior recommendation.

I'm mesmerized that that part worked in the patch provided before but wouldn't now, but will try still.

FYI: Here is an example of full dmidecode output on a coreboot system.

[tlaurion]

Double verified:
dmidecode -s bios-vendor |hexdump -C
00000000 63 6f 72 65 62 6f 6f 74 0d 0a |coreboot.|

I modified bootloader.py to check only for "coreboot" with same result: there is no "dmidecode -s bios-vendor returns coreboot" in /tmp/*

Any other insight?

[tlaurion]

Double verified:
dmidecode -s bios-vendor |hexdump -C
00000000 63 6f 72 65 62 6f 6f 74 0d 0a |coreboot.|

I modified bootloader.py to check only for "coreboot" with same result: there is no "dmidecode -s bios-vendor returns coreboot" in /tmp/*

Any other insight?

[marmarek]

Add logging of dmidecode output regardless of the match (i.e. save it
to some variable, log, then compare.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Add logging of dmidecode output regardless of the match (i.e. save it
to some variable, log, then compare.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

To speedup debugging, you can edit bootloader.py in the running installer, then start anaconda again (just launch it from console). It may require killing already running instance.

[marmarek]

To speedup debugging, you can edit bootloader.py in the running installer, then start anaconda again (just launch it from console). It may require killing already running instance.

[tlaurion]

The problem seems to be linked to python 3 dealing with output differently the 2.7.

To fix output validation, following block:

if subprocess.check_output(
                    ['dmidecode', '-s', 'bios-vendor']) == "coreboot\n":

needs to become:

 if subprocess.check_output(
                    ['dmidecode', '-s', 'bios-vendor'], universal_newlines=True) == "coreboot\n":

I'm installing right now on a x200 with libreboot flashed on. Sorry for the ping pong game again, learning my way into python, which is pretty neat.

Thanks, @marmarek

[tlaurion]

The problem seems to be linked to python 3 dealing with output differently the 2.7.

To fix output validation, following block:

if subprocess.check_output(
                    ['dmidecode', '-s', 'bios-vendor']) == "coreboot\n":

needs to become:

 if subprocess.check_output(
                    ['dmidecode', '-s', 'bios-vendor'], universal_newlines=True) == "coreboot\n":

I'm installing right now on a x200 with libreboot flashed on. Sorry for the ping pong game again, learning my way into python, which is pretty neat.

Thanks, @marmarek

[marmarek]

Automated announcement from builder-github

The package pykickstart-2.13-3.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package pykickstart-2.13-3.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package pykickstart-2.13-3.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package pykickstart-2.13-3.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update