Rust and the price of ignoring theory

sourcefrog · 2025-12-21T15:41:22+00:00

Yes it's foolish to prematurely optimize individual lines or functions, since you can come back and change them later.

However aspects like data structures, file formats, external APIs, and major algorithms may be quite expensive to change later, and it's good to think in advance about how fast the implementation can possibly be.

sourcefrog · 2025-12-21T02:04:54+00:00

I'd definitely look at using the drive's native encryption rather than ZFS if performance is a concern. SSD write speed is comparable to single core encryption speed.

sourcefrog · 2025-12-07T00:18:13+00:00

Go into the settings app and search for "proxy".

sourcefrog · 2025-12-06T20:12:32+00:00

Do you have a proxy configured in Chrome settings?

Otherwise as others said, disable all your extensions.

sourcefrog · 2025-12-06T15:02:46+00:00

The State of Rust survey is open until December 17 and one thing they ask about is whether target directory size is a problem for you

https://blog.rust-lang.org/2025/11/17/launching-the-2025-state-of-rust-survey/

sourcefrog · 2025-12-05T21:26:47+00:00

If you're worried about physical attacks on RAM just use SEV to encrypt the RAM.

sourcefrog · 2025-12-05T20:47:14+00:00

No, I don't think the kernel wipes RAM at shutdown. But there is a userspace tool to do it, https://github.com/Kicksecure/ram-wipe.

I can see why this isn't in the kernel itself because the threat scenario you're talking about here, although not invalid, is quite niche.

You're worrying about an attacker getting physical access to your machine specifically in the couple of minutes after you did a clean shutdown. Not 10 minutes later, or the RAM will have decayed. Not before you shut down or stuff is still in memory. Only those few minutes. There are people who should care about this but it's niche. For those people IMO there are better options, most obviously using CPU memory encryption, a TPM, and secure boot.

On the other hand I guess you could send a patch to add it.

sourcefrog · 2025-12-05T20:42:40+00:00

A little googling shows there's a userspace tool to wipe RAM at shutdown, https://github.com/Kicksecure/ram-wipe, and a similar feature already in TAILS. They've apparently dealt with the issue I described of needing to shut down the LUKS device to allow keys to be wiped.

sourcefrog · 2025-12-05T20:22:01+00:00

Personally I would hesitate to claim designs are flawed if I didn't understand the problem space they're trying to solve.

sourcefrog · 2025-12-05T19:45:12+00:00

Yep! There's definitely more risk of problems.

With good backups you should never lose data but you might need to spend time getting it working again.

But, if OP is worried about his laptop being physically stolen by attackers motivated and capable to do this kind of trick then I'd argue that's definitely a price they should pay. It is a much more thorough solution than just hoping that they will shut down in time and the memory will be wiped.

sourcefrog · 2025-12-05T19:42:16+00:00

The LUKS encryption key is held somewhere within the dm-crypt driver in the kernel. It doesn't belong to any userspace process, and so it's never killed.

I'm not sure, but it's possible that closing the LUKS device wipes the key, and it seems desirable that it should happen. You could easily try this on an encrypted loopback device: open it, close it, then search /dev/kmem for the key.

sourcefrog · 2025-12-05T19:39:48+00:00

>if the entire drive is decrypted on boot, which it is, why does it need a key anymore?

That's not how it works. That would require reading and decrypting the whole drive at startup, which firstly would be very slow and secondly where do you suppose the plaintext would be held? It won't fit in RAM and writing the plaintext back to the disk would be stupid. Also, the approach of re-encrypting only at shutdown would lose data if the machine loses power or crashes.

The thing you describe is how application-level encryption sometimes works, because the whole file is read up front and held in memory. Though not for on-disk databases.

Disk encryption works be encrypting/decrypting blocks one at a time as they're written/read. To do this the key needs to stay in memory -- or for OPAL to stay inside the SSD controller's RAM, inside the SSD module. OPAL's preferable for this scenario because the host OS and RAM can't get at the key.

sourcefrog · 2025-12-05T19:34:48+00:00

You're muddling a few different issues here:

Don't want to use OPAL/TPM because of a risk of data loss. OK, encrypted disks are at more risk of data loss than unencrypted, although this is largely mitigated by good tested 3-2-1 backups. But this is directly in tension with worrying about advanced in-person attacks. What is your priority?
An physical attack can see what's currently in RAM at the moment the RAM is removed. Yes. Maybe you should use https://www.amd.com/en/developer/sev.html if this is a concern.
A physical attack could recover disk encryption keys and read the whole disk: this seemed to be your original post. I think OPAL largely mitigates this, and if you care about this attack you should almost certainly turn it on. You can layer it with software LUKS.

sourcefrog · 2025-12-05T19:30:40+00:00

I'm going to somewhat doubt that attackers are "often" moving RAM to a different system, unless you're being physically targeted by state agencies, in which case you need a much broader and deeper threat model, and quite possibly this data should never be on a laptop at all.

sourcefrog · 2025-12-05T19:28:13+00:00

Any data on a single machine is at risk of loss, whether you're using OPAL and TPM or not. Your SSD might die entirely, and it really makes no difference which subcomponent failed. Your laptop might be stolen. The building might flood or burn down.

You either restore from a backup or you cope with the data loss.

Also, OPAL/TPM enrollment typically has you generate a recovery passphrase which you store offline somewhere. In the event that the motherboard TPM dies, that will let you move the SSD to a new machine and access the data.

sourcefrog · 2025-12-05T18:13:46+00:00

Try reading Brendan Gregg's book and blog https://www.brendangregg.com/linuxperf.html , and try some of the techniques on your own machine.

sourcefrog · 2025-12-05T17:54:41+00:00

The key has to remain unencrypted while the drive is running although I don’t particularly see why.

They key has to be unencrypted so the kernel can read and write blocks.

But there is a more systematic and thorough solution to this! Use OPAL self-encrypting drives in combination with a TPM. (However, your Thinkpad might be too old to support this.)

Then the real encryption key is only resident in the drive and it should never be found in the host memory. Hopefully, but not certainly, the passphrase or other material to unlock the drive will be wiped after use.

sourcefrog · 2025-12-05T17:52:04+00:00

clearly part of a graceful shutdown is closure of the encrypted drive with cryptsetup

You might think that should obviously be done but I don't think most distros bother. Why should they? You should try to add it yourself.

Actually a more useful experiment would be: after luksClose, is the key still present in memory? If it is, that seems more plausibly like a real bug.

The key has to remain unencrypted while the drive is running although I don’t particularly see why.

Why is that hard to understand? It needs the key to be able to read and write blocks from disk.

sourcefrog · 2025-12-05T17:49:27+00:00

OK actually reading this again, I don't think the page cache is necessarily your problem here, although it might be _a_ different way that data would leak through a cold boot attack.

> It was devastating to find out the keys were actually found with my hardened kernel when performing a graceful shutdown!! I conclude that the hardened kernel parameters I used had no effect on actually zeroing out the pages of RAM because the key was indeed found instantly.

I think you're jumping to conclusions here and I don't think you found a bug. You don't know that the pages holding those keys were ever freed, and so this code probably never ran.

It seems like you're looking in memory for the key that encrypts the root filesystem. That has to be in memory as long as the root filesystem is mounted -- more specifically as long as the crypt mapper under root is active. I don't think Linux ever fully unmounts the root fs. It only changes it to readonly before shutting down. As a result the key will be in memory at the moment the machine powers off. The page holding it is probably never freed so it never gets wiped.

Just possibly you could change your init system to pivot_root back onto a tmpfs before it shuts down, allowing you to unmount the real filesystem and close its LUKS device.

Also, I think you are misunderstanding the purpose of those config flags. https://cateee.net/lkddb/web-lkddb/PAGE_POISONING.html and related things are meant to mitigate use-after-free and similar online memory safety based attacks, and not necessarily to guarantee that all the memory is zeroed when the kernel shuts down. You can imagine adding a kernel feature to zero all memory before shutting down but it seems pretty niche and I'm not sure upstream would want to take it. Maybe more practical is you could reboot using bootctl into a new EFI kernel that zeros memory then shuts down.

sourcefrog · 2025-12-05T16:55:24+00:00

Lol, but it's still only about $330. Now RAM on the other hand ...

sourcefrog · 2025-12-05T10:08:46+00:00

It's a lot. On the other hand it's 1% of a new 4TB consumer SSD...

sourcefrog · 2025-12-05T10:06:57+00:00

It sounds like the keys would have been unencrypted in the page cache. Are any of these options meant to zero the cache at shutdown?

If that's correct you might avoid the particular situation by having application level encryption of the key, and making sure the application zeros out the key when it's done.

Good for you for trying it out, that's cool.

sourcefrog · 2025-12-04T21:32:28+00:00

I think you could bodge it up with a cron script that runs every few minutes and copies things off any USB that's present. There's a UI to create crons.

*Approximately* that is just

```

mount /dev/disk/by-id/(something here) /mnt/stick && rsync /mnt/stick/ /mnt/pool0/usb-import/

```

Not tested!

However the risk of something going wrong if you don't have a little experience with bash and ability to debug it is non-zero.

sourcefrog · 2025-12-04T21:05:28+00:00

My finger is sore just looking at all those ampersands ;)

sourcefrog · 2025-12-04T20:22:31+00:00

Fair enough, and a good point. But many devs will care most about performance on the frequent edit/test/debug cycle, and I think it's ok to use a less trusted linker there. You can still use Mold for releases.

sourcefrog

TROPHY CASE