QA » openQA Project » openQA Tests

From https://bugzilla.suse.com/tr_show_case.cgi?case_id=1769936:

Fully encrypt a system including /boot, it would look somewhat like this:
* MBR (grub2)
* /dev/vda1 -> LUKS -> LVM PV -> LVM VG -> LVM Volumes -> file systems
  (including /boot with kernel and initrd)

For this to work, grub2 needs to be able to open LUKS volumes by itself
(without initrd) otherwise it could not even read the kernel and initrd.
Luckily the grub2 in our product is able to do this, and our installer
does the right thing.

1, Install SLES15 SPx
    -- Input kernel option "fips=1" for installation (or skip here but enable fips=1 after installation)
    -- Click on "Edit Proposed Settings" and select "Encrypted LVM-based Proposal" at Suggested Partitioning, setup password, at least 8 characters
    -- Click on "OK"
    -- Click on "Expert Partitioner..."
    -- Right-Click on "/dev/sda1" (or /dev/sda1, the separate partition for /boot) -> Select "Delete" -> "Yes"
    The partition map looks like:
        /dev/vda
        /dev/vda1  Linux LVM
        /dev/system  LVM2 system
        /dev/system/root  LV  BtrFS  /
        /dev/system/swap  LV  Swap  swap
    -- Click on "Accept" to finish the disk partitioning.

2, Boot SLES15 SPx from harddisk
    -- Password will be asked for twice:
        * The first time is required by grub, before the grub menu displayed:
           "Attempting to decrypt the master key....Enter passphrase for hd0,msdos1(xxx):"
        * The second time is required by initrd when mounting the volume:
           "Please enter passphrase for disck cr_vda2!"

3, Check FIPS is enabled

From https://bugzilla.suse.com/tr_show_case.cgi?case_id=1769937:

Fully encrypt a system, but keep /boot on a separate unencrypted partition, it looks like the following:
* MBR (grub2)
* /dev/vda1 mounted to /boot (unencrypted!) with kernel and initrd
* /dev/vda2 -> LUKS -> LVM PV -> LVM VG -> LVM Volumes -> file systems

Here the bootloader just loads the unencrypted (!) kernel and initrd
from /boot. That initrd has support for encrypted volumes using LUKS and
is able to open it and continue booting.

1, Install SLES15 SPx
    -- Input boot option: fips=1
    -- Select "Encrypted LVM-based Proposal" at Suggested Partitioning, setup password

2, Boot SLES15 SPx from harddisk
    -- Input password to mount the disk partitions

3, Check FIPS is enabled

Note: Do not pass "fips=1" to installer boot option, seems installer doesn't support fips mode yet, see bsc#985969
Workaround is enable fips mode after installation: update grub.cfg and reboot.

Do we want this only for 15sp5 or also 15sp4?
And what archs?

We'll start with 15-SP{5,4} on x86_64. Then, if needed, we will implement other archs.

The system boots even with EFI and partitions set with separate boot and only with / encrypted. This is a very nice surprise, since the installer had to do some specific grub configuration and initramfs has to have support for this as well. I was expecting to have to deal with quirks like this. Very nice.

Note: Do not pass "fips=1" to installer boot option, seems installer doesn't support fips mode yet, see bsc#985969 Workaround is enable fips mode after installation: update grub.cfg and reboot.

The mentioned https://bugzilla.suse.com/show_bug.cgi?id=985969 seems to be fixed now. It is confirmed working in the installer in both BIOS and UEFI (15-SP4 x86).

# cat /proc/sys/crypto/fips_enabled
1

It seems like the tests are already written:

schedule/security/encryption/fips_lvm_encrypt_separate_boot.yaml
schedule/security/encryption/fips_lvm_full_encrypt_maint.yaml

although they are never scheduled and tests from yast/encryption/ are scheduled instead. I reckon we can delete the copies in security/encryption/, provided the yast versions work.

After talking with people from QE-YAM (yast), we concluded that it would be better to maintain our own clones of the schedules, because they are planning on rewriting them, which would most likely break for us.

Explained by Joaquin Rivera:

don't depend on us, we soon will break them, because we are using a new features for scheduling, where instead of a list of test modules we have keys for phases of the installation and a default file.
...
each squad is better to have their own copy, we favor that each squad work independently on those, than to try to be very efficient with one file, the second doesn't help, because a minimal change can break stuff in other squad.

Rewritten tests to cover more platforms: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17182
Waiting to be scheduled.