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

[Takashi Yamamoto <imuwoto2%gmail.com@localhost>]

On Sun, Mar 15, 2026 at 3:28 PM Takashi Yamamoto <imuwoto2%gmail.com@localhost> wrote:
>
> hi,
>
> On Sun, Mar 15, 2026 at 2:41 PM Taylor R Campbell <riastradh%netbsd.org@localhost> 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 PM 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.
> > >
> > > 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=1
> >
> > 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=1
> > in sysctl.conf, it would be better to have swap_encrypt=YES 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=1 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.