How much of a problem is the claim that privacy based OSes run in a vm are security risk due to leaving traces in swap?
 

I have seen that on the privacy OSes, advising not to run them in a VM as the swap file can store data beyond your session, but how long would this be the case?

Wouldn't it just be overwritten after running it your host again for a while without the vm running?

Of course threat model matters, and mine would be low, but I wonder how long these ghosts from your vm session could hang around in swap?

Only discussing with virt-manager not the other ones.

Could you not manually just flush the swap after a session to clear it?

Zero problem if no swap ...

https://discuss.privacyguides.net/t/...computer/12056

What is the threat vector? Do you expect someone with extensive expertise to steal or otherwise acquire your computer? Are you doing highly illegal things in the VM? If so, you can disable swap before starting the VM. That's easy to do, just run swapoff in a terminal, or if you're really worried, comment out any reference to swap in /etc/fstab and reboot without any swap. I use zram for swap, but on my system it rarely shows any use. That depends a lot on how much RAM is in the machine. If you have only 2 or 4 GB, then there will be a lot of swapping. With 32GB there will be little or none. I don't worry about it, because there is nothing in swap to concern me, but if you're really worried about this, just disable swap before you start doing illegal things.

Use ZSwap, swap to ram compressed and optionally encrypted. Wipes and recreates on boot. No traces.
Does require more memory allocation.

Indefinitely, until those specific blocks are explicitly overwritten or the drive is securely wiped.
No.
If your host has enough RAM and doesn't experience memory pressure, it won't trigger swap writes, leaving the old data untouched.

Furthermore, if the swap file is on an SSD, the drive's internal controller constantly moves data around to balance wear.
Yes.

If it's a traditional HDD, you can just turn swap off, shred the data and then turn swap on.
If it's an SSD, you would have to turn swap off, delete the file, and run fstrim, then recreating the swap file.

The best solution in my opinion would be to use an encrypted swap, eliminating the need for manual flushing and protecting the health of your drive if it's an SSD.

That being said, for a low threat model, this is an incredibly unrealistic attack vector to worry about.

Strict technically ... If I am not wrong ... that is not "safe/flush" ... because when you delete the file ... the information remains ... when you fstrim the swap ... the information remains ... and when you recreate the swap ... the information remains ... until you reboot your system and "information" was rewrite .... or not ...

The problem here was that you need to shred the data too in the SDD that is not good for the SDD life ... or wait until something overwrites it on the next reboot if you " turn swap off, delete the file, and run fstrim, then recreating the swap file" ...

EDITED: But seems @slackjawedyokel you are living in a "Hollywood film" ....

Hope that helps.

While physical data can technically persist on the NAND flash cells until garbage collection occurs, the rest of your claim and (AI?) source are wrong.

When you run fstrim (after turning swap off before deleting the file, which you forgot to mention), the filesystem informs the SSD controller which Logical Block Addresses (LBAs) no longer contain valid data.
Modern SSDs implement DZAT (Deterministic Read Zero after TRIM) or DRAT (Deterministic Read after TRIM) (see: https://rossmanngroup.com/technical-...-destroys-data).
The exact moment those blocks are trimmed, the drive's Flash Translation Layer drops the mapping between the LBAs and the physical NAND.

From that second onward, any standard read request sent to those LBAs immediately returns zeroes (or a fixed pattern), even before the physical cells are structurally erased by the controller's internal garbage collection.
Because standard data recovery software relies on OS read commands, it will only see zeroes, making it completely useless.

To recover data from a trimmed block before it is physically erased, an attacker would need specialized forensic equipment to bypass the controller and read the NAND chips directly (chip-off recovery). This is a highly complex process that can cost thousands of dollars, with no guarantee of success, and it is even more likely to end in a failure on newer SSDs because they use always-on hardware encryption (see: https://mdrepairs.com/blog/chip-off-data-recovery/ and https://www.crucial.com/support/arti...are-encryption).

Shredding or manually zeroing out a specific file on an SSD is completely ineffective and causes unnecessary write wear.
Due to wear leveling, the SSD controller can write the new zeroes/data to an entirely different physical block.

As suggested earlier, using an encrypted swap file completely eliminates this entire issue.

Ultimately, for this data persistence to present an actual security risk, an adversary would need:
1) Physical possession of your SSD.
2) Thousands of dollars and specialized hardware to read the NAND flash directly.
3) The luck that the SSD's internal garbage collection hasn't already physically erased the unmapped blocks.
4) Most likely an outdated SSD that lacks hardware-level or full-disk encryption.

This is a purely theoretical threat model. Unless you are actively targeted by a well-funded nation-state, it is not a practical risk a regular user needs to worry about.

I assume this is in reference to his other thread, it is completely irrelevant to the technical facts being discussed here.

In general, anything that we "borrow" from another operating system (such as resources in a virtual machine) can have traces outside of the current operating system (the virtual machine). As mentioned, we can encrypt our swap space, make sure it is erased, or not use it at all.
But don't forget, if I were really paranoid I would kill your VM to avoid cleanup and look for interesting info. Or dump the running VM to work with. Or they may have even better ideas.
How long will they stay (I mean the traces)? Until they are really wiped out.

Well not all people have the latest sdd who knows ...

https://blog.elcomsoft.com/2025/06/w...ssd-forensics/

EDITED: That is not AI ...

Is in reference nothing ... seems @slackjawedyokel are living in Eliot world ... because the asked questions ... as you said it is secure share an ip for "normal users" rear well configured firewalls ... but it is normal too to encript a swap for a "normal user"? ... seems "Hollywood" ... dunno.

Normal users don't do/ask that things ... IMO. Almost I don't do it. My paranoid level was not for encript/delete a Swap ... because I don't do bad things ... but who knows.

EDITED: I don't think that if you lose your laptop someone waste time and effort to recovery nothing in swap ... how % it will happens? Hollywood again ...

You say it references nothing, yet everything you mentioned was taken directly from his other thread here.
Furthermore, nobody else mentioned IPs in this thread. You are dragging irrelevant topics from other discussions into this one—despite the fact that I already dropped that subject there because the conversation was just going in circles—instead of staying on topic.

There is also no reason for personal attacks.
I don't know what you consider "normal," but the OP never even stated they were going to alter swap or use a VM—they asked a specific security question based on text they read.
Your solution was essentially "just don't use swap" while showing off your 32GB of RAM. Many people run systems with 2, 4, 8, or 16GB of RAM and absolutely need swap. Telling someone who asks a general conceptual question "just don't use it" is both unhelpful and poor advice.
The fact that you don't do it is completely irrelevant to whether the practice itself is secure.
For an average user, the risk of someone extracting sensitive data from swap after a laptop theft is very low, but it remains a valid theoretical threat.
It is similar to the theoretical risk of visiting Facebook, clicking a picture, and hitting a zero-day exploit chain that infects your browser and escapes a VM or Flatpak.

Practically speaking, these types of sophisticated, targeted attacks almost never happen to low-profile users. Theoretically, however, the vector exists, which is exactly what was being discussed.

EDIT:
Sure, it is not AI, but it is also not what you originally posted.

What you posted originally claimed:
Yet the link you just provided says something else completely:
Your own source explicitly states that the OS tells the SSD which blocks are no longer in use.
That directly contradicts your initial assertion that "fstrim tells the filesystem.".
The link disproves your own argument.

Hmm well I have low RAM at only 4GB. Running just a single vm and if I forget and open a single browser instance this can lock my machine forcing me to long press the power button to shut it down.

So turning it off completely would not be an option I think.

It is emmc for the main one with supplemental sdcard so both kinda ssd?

Yes it is low, but still it makes me feel more comfortable to wipe and not have stuff hanging around indefinitely in an unencrypted state. Similar to how probably nothing would happen if you kept all your passwords in an unencrypted text file in your home directory but you still want to encrypt them for mental comfort.

Encrypted swap sounds like a good choice for simple peace of mind.

EDIT: Btw, does simply putting the OS to USB stick instead avoid the issue entirely? I guess so, for example with TAILS OS, which is made for that and that is what they say on their advice against using it in a VM, that their security features are meant for VM only. Interestingly I read a thread on whonix forums that it too suffers from these same vulnerabilities but they are not clearly highlighted like they are on TAILS yet that OS is made to run in vms specifically.

The encrypted swap sounds a good solution though in either case if running vm or avoid the issue in the case of TAILS by just running from USB like you are meant to. For my low threat model though firing up a vm is more convenient, with the encryption of swap seems preferable.

Good discussion so far though! I have learned from the replies, similar to the other thread (which viel claims not to have referenced but obviously did but wouldn't admit it, lol).

Hmm why is it called zswap, just because it is compressed? As above I have only 4GB so I was also looking to increase my swap files so while looking to encrypt I may look to increase as well.

The base emmc only has 4GB but I have not used the 256GB sdcard hardly at all so have many GB to play with there.

Lol I too wondered why they bring that back up here.

In reference at my post ...

Well I can't find any reference to you or the other thread ... only reference at the questions he ask ...

So You said that It seems you have such high self-esteem that everything revolves around you.

and I response that

So I am try to explain you that "is not about you" is that I understood (in the post you know and you start talk about ) that some "normal people" don't need to worry about "ip's" open ports or encrypted swap ... so I understood that for "normal users" can be good to share their Ip without risk ... and don't need to worry about delete swap ... IMO if I recommend to encrypt the swap I will recommend to don't share an IP ... dunno ... seems I explained bad .... but seems you overreacted ...

As I said in the other thread, I appreciate your comments... even though I don't agree 100%, and less and less so...

OTOH ...


Maybe I used in this case an AI response because I am searching other things so to don't need to write to much... but no excuses ... you right maybe are more correct to say that " fstrim tells the filesystem (indirectly)"

but not for that what I write was bad rigth?

So seems you are a fixation to point that I write ... but seems you don't like that some point you ...( about supposing all people have routers secure ... or that all have the last SDD disks ...) you talk so well technically and you point others... but some times your "supposes" can be pointed too ... so please ... We may not agree that sharing an IP address is a good thing... or that encrypting the swap wasn't excessive... but please stay calm and don't overreact... I would appreciate it. Sure you too. :)

In conclusion... perhaps my answer to the question about the swap is vague... but not incorrect... this is because I don't think @slackjawedyokel don't need to worry about the swap... unless he live in a "Hollywood thriller"... then I'd worry about protecting the IP too... I think it's just curiosity... not necessity...(almost no reasons have explained) maybe I was lazy, I admit it.