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: Takashi Yamamoto <imuwoto2%gmail.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, imuwoto%gmail.com@localhost
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Sun, 15 Mar 2026 05:41:46 +0000

 > Date: Sun, 15 Mar 2026 14:05:57 +0900
 > From: Takashi Yamamoto <imuwoto2%gmail.com@localhost>
 >=20
 > On Sun, Mar 15, 2026 at 1:40=E2=80=AFPM Taylor R Campbell via gnats
 > <gnats-admin%netbsd.org@localhost> wrote:
 > >
 > > 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.
 >=20
 > if you want to test the performance impact, you don't want to have
 > encrypt/unencrypt pages mixed, i suppose.
 
 For serious performance testing, sure.
 
 For casually checking whether the impact is noticeable or not, it is
 nice to be able to just flip a switch and see whether the system
 starts to get sluggish, and whether the underlying swap file/device
 has recognizable memory or gibberish in it.
 
 > my proposal is just a global knob (vm.swap_encrypt) which can't be
 > changed if any swap devices are configured.
 
 What should happen if you try to set
 
 vm.swap_encrypt=3D1
 
 in /etc/sysctl.conf, but a swap device is already configured by the
 time it is executed?
 
 Here are some possibilities:
 
 1. The system fails to boot to multi-user and drops to single-user.
 
 2. The system boots but swap is all plaintext.
 
 The status quo, in contrast, is:
 
 3. The system boots and all memory swapped _after_ /etc/rc.d/sysctl is
    ciphertext.
 
 This is still possibly problematic -- but I think it's unlikely for
 any secrets to be swapped at this point.  It looks like the only
 relevant rc.d scripts that run between /etc/rc.d/swap1 and
 /etc/rc.d/sysctl are random_seed and ipsec, and except on extremely
 low-memory systems, they aren't likely to swap (the big one likely
 requiring swap is /etc/rc.d/fsck).
 
 So I think (3) is better than (1) or (2) on most machines for most
 users.
 
 Of course it would be better for security to have never swapped
 plaintext in the first place.  Perhaps, rather than vm.swap_encrypt=3D1
 in sysctl.conf, it would be better to have swap_encrypt=3DYES in rc.conf
 so another rc.d script which runs before /etc/rc.d/swap1 (and
 therefore before /etc/rc.d/sysctl) can make the change before swap is
 configured -- that way at least you don't need a kernel rebuild to
 enforce it.  But, of course, changing things six years on is risky
 because users may have started to rely on vm.swap_encrypt=3D1 in
 sysctl.conf.
 
 I don't object to changing how this works -- I just want to make sure
 that we have a clear plan for ensuring users have an easy path to good
 security, without regressions for existing users.