Add support for installing with FDE.

[WhatAmISupposedToPutHere]

This is more of a RFC, but this approach can successfully install fedora with fde straight from macos.

[marcan]

So, this is clever. I think the future is Anaconda-based installs, but I'm not fundamentally opposed to the qemu trick, because it might allow a fun segue: running Anaconda in qemu straight in macOS.

I see one major issue with the implementation here, however: the temp files. We can't assume there is enough disk space to stage the images as files; this is why the installer makes a point to stream everything from the internet. Can't we just install as normal and then run qemu directly on the disk partitions?

Distribution is a side issue: I'd want for everything to be self-contained to this repo as much as possible. Ideally we pull qemu from some public source, and add whatever else we need. The whole thing also should be more configurable, e.g. maybe approach it as a "postinstall" step. We could and probably should bundle the kernel/initramfs as part of the distro image itself instead, and only deal with qemu in the installer. That way different distros could approach this differently depending on their requirements for configuring FDE, and then it would nicely segue into an Anaconda-type thing without changes to the code. It would also allow the exact same mechanism to be used to launch a rescue environment to fix boot issues. There are a lot of nuances involved in getting all this right for those use cases though (e.g. you need to get the firmware/m1n1 scripts to work properly in a virtual environment), but for the simple "set up FDE" use case as you do here, you don't really need any of that.

[WhatAmISupposedToPutHere]

I see one major issue with the implementation here, however: the temp files. We can't assume there is enough disk space to stage the images as files; this is why the installer makes a point to stream everything from the internet. Can't we just install as normal and then run qemu directly on the disk partitions?

That should be possible, the reason i re-encrypt as macos temp files is because i did not want unencrypted data to hit the disk at all, but other tradeoffs can be made.

Distribution is a side issue: I'd want for everything to be self-contained to this repo as much as possible. Ideally we pull qemu from some public source, and add whatever else we need.

qemu is the annoying part to package, they do not provide macos builds, and have library dependencies that also need to be built. If you are ok with compiling qemu and a bunch of other libraries in installer's makefile (all of this is big and takes a minute to compile), then that could be a solution.

The whole thing also should be more configurable, e.g. maybe approach it as a "postinstall" step. We could and probably should bundle the kernel/initramfs as part of the distro image itself instead, and only deal with qemu in the installer.

That was my idea too, however since i did not want to patch and host my own version of installer_data.json just for this mostly-rfc, i bundled it with qemu for now. But yes, fully agree that it should be a part of distro image

[tobiasgrosser]

This is super interesting. I was working on sth similar and wrote a python-only luks encryption tool here:
https://github.com/opencompl/pyluks. It's still an early prototype, but this might enable us to do encryption without having to pull in full qemu. If pyluks could be of any help, let me know and I can fix things over the holidays.

[WhatAmISupposedToPutHere]

This is super interesting. I was working on sth similar and wrote a python-only luks encryption tool here: https://github.com/opencompl/pyluks. It's still an early prototype, but this might enable us to do encryption without having to pull in full qemu. If pyluks could be of any help, let me know and I can fix things over the holidays.

Unfortunately, you will also need to write pyext4 and pybtrfs, when installing with fde, the disk images need to be patched a bit. However i would be happy to be proven wrong.

[tobiasgrosser]

This is super interesting. I was working on sth similar and wrote a python-only luks encryption tool here: https://github.com/opencompl/pyluks. It's still an early prototype, but this might enable us to do encryption without having to pull in full qemu. If pyluks could be of any help, let me know and I can fix things over the holidays.

Unfortunately, you will also need to write pyext4 and pybtrfs, when installing with fde, the disk images need to be patched a bit. However i would be happy to be proven wrong.

To which degree do they need to be patched? And how did we manage to create disk images until now without qemu but with exactly the right content? AFAIU for ubuntu asashi https://github.com/tobhe is building custom images, anyhow. I would expect those to contain luks support (and maybe have an updated boot line, but otherwise to remain pretty unchanged).

[WhatAmISupposedToPutHere]

This is super interesting. I was working on sth similar and wrote a python-only luks encryption tool here: https://github.com/opencompl/pyluks. It's still an early prototype, but this might enable us to do encryption without having to pull in full qemu. If pyluks could be of any help, let me know and I can fix things over the holidays.

Unfortunately, you will also need to write pyext4 and pybtrfs, when installing with fde, the disk images need to be patched a bit. However i would be happy to be proven wrong.

To which degree do they need to be patched? And how did we manage to create disk images until now without qemu but with exactly the right content? AFAIU for ubuntu asashi https://github.com/tobhe is building custom images, anyhow. I would expect those to contain luks support (and maybe have an updated boot line, but otherwise to remain pretty unchanged).

The patches include changing boot lines, but one of the parts is a uuid that is generated by cryptsetup. You can see the whole script here. https://github.com/WhatAmISupposedToPutHere/encryptor/blob/main/init

[tobiasgrosser]

Does the cryptsetup UUID need to change across installations. As far as I know, Asahi uses the same UUIDs for all installations, no? Would choosing a fixed one make things easier. At least the pyluks tool that I wrote can set arbitrary UUIDs for the encrypted partition.

[marcan]

I see one major issue with the implementation here, however: the temp files. We can't assume there is enough disk space to stage the images as files; this is why the installer makes a point to stream everything from the internet. Can't we just install as normal and then run qemu directly on the disk partitions?

That should be possible, the reason i re-encrypt as macos temp files is because i did not want unencrypted data to hit the disk at all, but other tradeoffs can be made.

The unencrypted data is public data at this point, so I don't think there's any point to doing that.

[WhatAmISupposedToPutHere]

I see one major issue with the implementation here, however: the temp files. We can't assume there is enough disk space to stage the images as files; this is why the installer makes a point to stream everything from the internet. Can't we just install as normal and then run qemu directly on the disk partitions?

That should be possible, the reason i re-encrypt as macos temp files is because i did not want unencrypted data to hit the disk at all, but other tradeoffs can be made.

The unencrypted data is public data at this point, so I don't think there's any point to doing that.

Yes, already changed that.