Re: kern/60084: swap encryption: per-page tracking seems overengineered

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

[resent via correct MTA for @NetBSD.org and with correct magic subject
line, apologies for duplicates]

> Date: Sun, 15 Mar 2026 03:36:53 +0000 (UTC)
> From: imuwoto%gmail.com@localhost
> 
> swap encryption maintains a bitmap to track per-page encryption
> status. it's wasteful and unnecessarily complicate the implementation.
> it would be simpler to let user decide it at swapon time.
> after all, i suppose a user would either wants to encrypt all of the
> swap, or none of them. not any middle of them.

The most important part is to make it seamless for users, so it's not
some bizarro hardening knob that only bizarro security nerds will mess
around with (like swap-on-cgd or cgdroot-ramdisk).

Requiring a reboot (or, worse, kernel rebuild) to test the performance
impact in a real workload would be annoying, so I made sure there is a
way to enable and disable it dynamically.

I considered implementing a per-device flag for swapon, but that would
entail changes to userland, questions about compat, and generally a
more complicated interaction with users than the sysctl setting.  So I
went with a simpler-impact change at a slightly higher cost to the
internal implementation.

I wouldn't object to adding a per-device flag but I didn't want to
think about all the parts that have to fit together to make it work --
and make sure it happens by default, without users having to think
about it.

Perhaps, rather than a flag for swapon, each swap device should simply
record the value of vm.swap_encrypt when it is configured -- that way,
a whole swap device at a time will be ciphertext or plaintext, but
there's no other userland interface changes, and it still doesn't take
a kernel rebuild or reboot to make a change.

However, this would mean that after you set vm.swap_encrypt=1, you are
_not_ guaranteed that subsequent swapped pages will be encrypted; you
are only guaranteed that if you _also_ do a swapoff/swapon cycle.
That's _probably_ fine, as long as we update the sysctl(7) man page
(and hope everyone who read it before reads it again), but it's a
little less seamless and could cause security-destroying confusion.

> that way the encryption key can be generated at swapon time too.

Deferring key generation until the latest moment before it is actually
needed helps to maximize the amount of data fed into the entropy pool
before generating a key, for the benefit of machines without HWRNG.

Since key generation doesn't allocate any memory, what is the
motivation to do it earlier?  Saving one byte of memory per swap
device that records whether the key has been generated?  We could
probably achieve the same by reordering some struct swapdev members.