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:29:57 +0900

 On Sun, Mar 15, 2026 at 3:28=E2=80=AFPM Takashi Yamamoto <imuwoto2%gmail.co@localhost=
 m> wrote:
 >
 > hi,
 >
 > On Sun, Mar 15, 2026 at 2:41=E2=80=AFPM Taylor R Campbell <riastradh@netb=
 sd.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 performa=
 nce
 > > > > impact in a real workload would be annoying, so I made sure there i=
 s 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.
 
 i meant "before". oops.
 
 > 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.con=
 f
 > > 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.