# 20240506_coreos-s390x-secex What are the differences between regular s390x VM images vs Secure Execution s390x VM images? - add `sdboot` partition, and `verity` partitions (one for boot and one for root) - `sdboot` ext4 - `verity` -> verity thing - generate verity hashes for boot/root so we can verify on first boot that they haven't been tampered with - make a filesystem on the `sdboot` partition and place an encrypted kernel and initrd in it - encrypt the kernel and initrd and place them here - add the ignition private key to the initramfs - the ignition private key can be used to decrypt the Ignition config that is provided to the system on boot - this key gets used and deleted on first boot - populate parmfile with current kargs - append the verity hashes to the kernel command line - run genprotimg to generate an encrypted file which includes the kernel, initrd, and kargs/parmfile - what key is used here? - for RHCOS; the generic s390x IBM key - customers on first boot need to replace it with the machine-specific key - place this encrypted file on the `sdboot` partition - run `zipl` to tell the VM what to boot - on first boot, boot and root are encrypted, sdboot blob (kernel/initrd/parmfile) is re-encrypted with customer key: - https://github.com/coreos/fedora-coreos-config/blob/testing-devel/overlay.d/05core/usr/lib/dracut/modules.d/35coreos-ignition/01-secex.ign ----------- - generate an encryption key to be used for Ignition - public key gets output by the build process and shared with customers - private key gets baked into the initramfs (that is packaged up using genprotimg) and used to verify that only Ignition configs signed with the public key can succeed - set up verity for /boot and /root - 2nd partition for each that we run veritysetup on - take the hash from when we run veritysetup and then store those hashes on the kernel command line (i.e. this then gets taken and verified by something on first boot) - the kernel command line gets encrypted with the host key so passing the information this way is protected - generate a bootable payload (sdboot) - covers kernel, modified initramfs (i.e. with the Ignition secret key appended) and kernel command line (i.e. parmfile) - signed by host key - stored in "sdboot" partition (the one with the `se` label/name) in a file called `sdboot` - run zipl across the generated sdboot so the machine knows what to boot ## Proposed path forward Idea: Keep the 2 paths as identical as possible 1. Generate gpg key outside of osbuild as pre-step 2. Do not encrypt anything during osbuild -> post step necessary in both cases 3. Run the runvm.sh script either with or without passing it a hostkey - When run without hostkey, it will use the pre-built production VM to encrypt sdboot - When run with hostkey, it will create a adhoc VM that repeats the same steps, but signs with the provided hostkey