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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60084; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: imuwoto%gmail.com@localhost
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Sun, 15 Mar 2026 04:36:54 +0000

 [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.