While browsing the grub‑live wiki I discovered that neither grub‑live nor Tails clears VRAM when the system shuts down.
When the system powers down, the kernel stops the CPUs and tells each driver to simply hand the device back to the firmware. The firmware may or may not clear the memory when power is removed. Complete loss of power guarantees erasure usually right?
With the nohibernate flag now in play, could this interfere with reaching the deepest D3 cold power state? I’m no computer scientist, but my intuition says there shouldn’t be a direct link.
Has anyone published research on this topic? Is a reliable feature even feasible for Kicksecure?
How could you turn the GPU off before the CPU?
Does an already normal linux shutdown put devices in D3 cold?
For context, I’ve been looking at kernel GPU parameters and both AMD and Radeon expose runtime power management flags that let the GPU request D3 Cold.
Building on a previous discussion about dracut and grub‑live, I’m wondering whether we can leverage rd.driver.pre= and rd.driver.post= to force the amdgpu module to load inside the initramfs before the real root mounts. Then keep that module loaded after the real root is mounted so it is still present when the dracut‑shutdown stage runs? I’d presume that it wouldn’t be as simple as just this alone. Something like the ram-wipe Dracut module?
There are a lot of questions here; generally it’s better to have one forum post per question to keep things easy to track. (We use posts, especially development posts, to track individual things that need worked on, so keeping one topic per post makes us able to do that.)
It’s supposed to, and in practice it usually does. Unfortunately, it doesn’t always do so, 3mdeb did some research on how different RAM responds to power loss and some of it can maintain a substantial amount of data for alarmingly long. (One particular 4GB DDR4 DIMM from Kingston ended up retaining a tiny, but recognizable, amount of data for two minutes after power loss. Most other memory tested didn’t do that, but it’s dependent on the particular RAM you have.) See:
Many systems (all of them except for those with discrete GPUs) have video and system memory on the same RAM modules, so turning off the GPU first probably wouldn’t help much. What would help is the ability to wipe RAM when it’s no longer used, which we try to do via the kernel parameters init_on_alloc=1 and init_on_free=1 (both of which are set in security-misc-shared). It’s unclear if the Intel and AMD graphics subsystems actually obey these kernel parameters though; if the GPU reserves memory entirely for its own use, it might be out of the kernel’s control. Systems with discrete GPUs are even less likely to obey those settings.
We have a task made to look at wiping VRAM (ToDo for Developers), but it’s pretty low in the priority list.
Sorry for posting in the wrong section, it’s hard for me to keep my thoughts and questions in one place. Thanks for the 3mdeb links will check them out
Many systems (all of them except for those with discrete GPUs) have video and system memory on the same RAM modules, so turning off the GPU first probably wouldn’t help much.
Yes, those are the ones I was thinking of were the discrete GPU’s, the ones you install in the PCIe slots. Lots of security risks with them hence why Qubes disables them and only allows integrated.
will check them out