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: Taylor R Campbell <riastradh%netbsd.org@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 15:28:54 +0900

 hi,
 
 On Sun, Mar 15, 2026 at 2:41=E2=80=AFPM Taylor R Campbell <riastradh@netbsd=
 .org> wrote:
 >
 > > Date: Sun, 15 Mar 2026 14:05:57 +0900
 > > From: Takashi Yamamoto <imuwoto2%gmail.com@localhost>
 > >
 > > 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 performanc=
 e
 > > > 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.
 >
 > 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?
 
 it won't happen for normal users because
 /etc/rc.d/sysctl is executed after /etc/rc.d/swap1.
 we have the "DISKS" barrier between them.
 
 >
 > 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.