Reclamation of UEFI-reserved Memory During Runtime

[human00731582]

Greetings to all.

I have recently been doing more work on my UEFI loader for fully encrypted boot media. For systems which can read and mount filesystems from ACPI NFIT information, this is working great: I plug in my prepared USB, power on, give the right password, the ramdisk is loaded, AES decryption completes, and control transfers to the disk's own stage-1 loader. Sick.

This is excellent for installation media. I can wall any OS installer supporting ACPI NFIT filesystems behind this crypto and create completely confidential and tamper-resistant installers. Once the installer does its job, the system reboots into the new OS. Great.

However, this system does not play so nicely with boot partitions that load a full, already-installed operating system. While it works--the initial ramdisk is decrypted and boots into the system--the amount of memory reserved from the first-stage UEFI chainloader (read: my work) remains after the boot process is completed. I want to release this reserved memory (ramdisk) after booting off it.

I was investigating options for runtime drivers, or using something using UEFI's Events and Signals support to release memory back to the runtime OS for use. It's not great always missing a substantial chunk of main memory after booting.

This seems to be a very specific request, and I'm not sure where to look for examples of doing so, so I am turning to this community for any help I can get.

• Does anyone know where I might be able to start?
• What is the best and least "hacky" mechanism to use here?
• Should I even do this? Since the kernel is loaded from the initrd into a different memory location after booting completes, theoretically releasing the boot ramdisk should not affect any runtime operations. The boot ramdisk acts strictly as an initial and read-only filesystem.

I have also encountered strange behavior with reserving the sequential space for these [large] ramdisks. For example, a 1.8G encrypted boot image (huge, I know) on a system with 8G of RAM will fail to load, while it works fine on others with the same limitations. I've attributed this to a swiss-cheese memory mapping, where no sequential 1.8G slot exists for the ramdisk. So I guess the solution for this one is just "More RAM = Better"(tm).

I do of course plan on giving back and open-sourcing this project (i.e., sharing with the community) once the work is complete.
Thanks in advance for any input.

[Octocontrabass]

Does anyone know where I might be able to start?

I'd start by figuring out if loading an entire disk image into memory is necessary. Can you make it work with just the boot partition?

What is the best and least "hacky" mechanism to use here?

The only thing I can think of would be somehow using ACPI to provide an eject function that removes the RAMdisk and installs RAM in its place. I don't know if ACPI has the pieces necessary to do that, and I don't know how you'd convince the host OS to use it.

Should I even do this? Since the kernel is loaded from the initrd into a different memory location after booting completes, theoretically releasing the boot ramdisk should not affect any runtime operations. The boot ramdisk acts strictly as an initial and read-only filesystem.

That'll work for Linux, but I'm not sure if other OSes (Windows) will play nicely.

[human00731582]

I'd start by figuring out if loading an entire disk image into memory is necessary. Can you make it work with just the boot partition?

Ah, I'm sorry, I should have been clearer here: the encrypted image being loaded as a ramdisk is only the boot partition for an OS and not a whole disk's image (at least in the case of already-installed systems and not installation media). This allows other data partitions to be encrypted with something like LUKS or whatever else the host originally used.

The only thing I can think of would be somehow using ACPI to provide an eject function that removes the RAMdisk and installs RAM in its place. I don't know if ACPI has the pieces necessary to do that, and I don't know how you'd convince the host OS to use it.

Good point and idea, I'm going to need to investigate this option. My biggest hurdle here seems to be keeping everything as OS-independent and generic as possible, since I want this to be a universal boot partition/media encryption method. I suppose at the end of the day, it really is up to the OS to make a decision as to whether to use the ramdisk, and to subsequently call the ACPI hook.

I provide two EFI variables to the host OS: the physical address of the boot ramdisk as well as its length. This lets OSes without NFIT support still find the ramdisk if they have a branch which 'looks' for these variables. Perhaps an OS driver might run a oneshot-style service to reclaim this memory after reaching a certain boot target (speaking in terms of systemd here), but that's unfortunately OS-dependent.

Another idea I had was to install a UEFI Runtime Services driver that can just do some sort of time-release FreePool on the ramdisk, and maybe that could trigger the ACPI hook itself to indicate more RAM has become available or hotswapped. The biggest problem here becomes (1) whether FreePool is useable after ExitBootServices, and (2) whether the chainloaded GRUB or other OS bootstrapping will destroy the runtime driver's handle from my first-stage loader.

I surely have some work to do. I realize it's a bit of an ambitious project, but at least it works for installation media supporting NVDIMM storage mappings. I guess that's cool.

[Octocontrabass]

whether FreePool is useable after ExitBootServices,

It's a boot service, so no, you wouldn't be able to use it.