Investigate: Wipe memory at startup with QOS bootloader

[emostov]

"on hardware wallets, one of the incomplete but helpful defense mechanisms is that an early part of the boot (bootloader) wipes some or all of the unused volatile memory before giving control to some firmware component. This way, even if the newly loaded firmware is malicious or buggy and the previously loaded firmware left something important in RAM, there's a good chance that it's wiped before it can get leaked. This is relevant since power of the embedded devices can be pulled at any moment, so this is a common scenario."

"For QuorumOS, a similar concept may help in cases where the attacker can e.g., "only" get control or find a memory leak vulnerability in a rebooted state after a previous panic, unexpected shutdown or other error condition. In that case, wiping the initial memory just in case could avoid practical impacts." ... "Also, it's likely the AWS Nitro VMs already have a thoroughly cleared memory on any logical restart since this is an obvious security problem otherwise. Still, I thought this is worth mentioning concept-wise." (@cr-tk)

ref: #122

[cr-tk]

As mentioned on Slack and quoted above, ideally the AWS Nitro system already does this "for us". It would be great if the AWS Nitro documentation promises this state (vs. just finding out it's usually the case experimentally).

Unlike tasking an early QOS stage with zero-ing the memory, having AWS logic do the wiping for us would also cover information leaks in situations where a malicious QOS is started after a non-malicious QOS is stopped/frozen/aborted/..

With DDR4 server RAM, we're probably looking at something like 15 to 25GB/s of raw memory bandwidth per populated CPU memory channel in the best case, and there are probably 8 of those directly connected to the server CPU internally in the AWS machine (with potentially a Dual-CPU or Quad-CPU setup and NUMA, but comparably slow inter-CPU communication). A back-of-the-envelope calculation for the theoretical best-case time of a full memory overwrite of a 1GB RAM region of a VM would be in the order of 10ms.

Ideally, the underlying AWS setup works more cleverly when it comes to logical vs. physical memory pages and doesn't hand a new VM any physical memory pages that aren't cleared. In other words, the newly started VM shouldn't have to spend many milliseconds just brute-force overwriting memory, but it's at least worth looking into the status quo.

I'm mentioning the raw memory overwrite performance topic because that is IMHO a major driver why "older" and performance-focused systems like memory allocation in C don't clear memory by default (e.g., cleaning stack memory or stack frames after use or cleaning previously used heap memory before making it available via malloc()). For embedded systems, the SRAM persistence between resets can actually be (mis)used as a feature to communicate information across the reset.

Reasonable virtualization systems however should IMHO default to handing guests only sanitized memory, so I assume this is less of an issue in the hardened environment we're targeting.