Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full encrypted disk support on coreboot/libreboot BIOS machines #2118

Closed
tlaurion opened this issue Jun 26, 2016 · 22 comments
Closed

Full encrypted disk support on coreboot/libreboot BIOS machines #2118

tlaurion opened this issue Jun 26, 2016 · 22 comments
Labels
C: installer r3.2-dom0-stable T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.

Comments

@tlaurion
Copy link
Contributor

tlaurion commented Jun 26, 2016

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

@andrewdavidwong andrewdavidwong added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. C: installer labels Jun 27, 2016
@tlaurion
Copy link
Contributor Author

tlaurion commented Jul 14, 2016

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
Copy link
Member

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
Copy link
Contributor Author

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 added a commit to marmarek/qubes-installer-qubes-os that referenced this issue Jul 14, 2016
With grub payload it is possible to have all the partitions encrypted.

Fixes QubesOS/qubes-issues#2118
marmarek added a commit to marmarek/qubes-installer-qubes-os that referenced this issue Jul 14, 2016
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
@marmarek
Copy link
Member

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

@marmarek
Copy link
Member

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

@tlaurion
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

tlaurion commented Jul 14, 2016

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
Copy link
Member

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
Copy link
Contributor Author

tlaurion commented Jul 15, 2016

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
Copy link
Member

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
Copy link
Contributor Author

tlaurion commented Jul 16, 2016

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
Copy link
Member

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

@tlaurion
Copy link
Contributor Author

tlaurion commented Jul 16, 2016

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

tlaurion commented Jul 18, 2016

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
Copy link
Member

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
Copy link
Member

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

fepitre added a commit to fepitre/anaconda that referenced this issue Sep 20, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 20, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 20, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 20, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 20, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 20, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 20, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 21, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 21, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 21, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 21, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 21, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Sep 22, 2017
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 14, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 14, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 18, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 18, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 18, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 18, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 18, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 18, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 19, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 19, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre added a commit to fepitre/anaconda that referenced this issue Oct 20, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
fepitre pushed a commit to fepitre/anaconda that referenced this issue Oct 20, 2018
With grub payload it is possible to have all the partitions encrypted.

Based on patch by @tlaurion

Fixes QubesOS/qubes-issues#2118
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: installer r3.2-dom0-stable T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Development

No branches or pull requests

3 participants