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

["Takashi Yamamoto via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Takashi Yamamoto <imuwoto2%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	imuwoto%gmail.com@localhost, riastradh%netbsd.org@localhost
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Sun, 15 Mar 2026 14:05:57 +0900

 hi,
 
 On Sun, Mar 15, 2026 at 1:40=E2=80=AFPM Taylor R Campbell via gnats
 <gnats-admin%netbsd.org@localhost> wrote:
 >
 > 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 overeng=
 ineered
 > 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.
 
 if you want to test the performance impact, you don't want to have
 encrypt/unencrypt pages mixed, i suppose.
 
 >  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.
 
 my proposal is just a global knob (vm.swap_encrypt) which can't be
 changed if any swap devices are configured.
 
 >  However, this would mean that after you set vm.swap_encrypt=3D1, 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.
 
 with the current machinery, if a user wants to ensure all swaps are encrypt=
 ed,
 he has to ensure no swap slots are used when he turned vm.swap_encrypt on.
 it's essentially the same as a swapoff/on cycle.
 
 >
 >  > 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.
 
 it makes sense. i added a comment in the code.
 
 >  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.
 
 i wanted to simplify swap io logic.