NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/60084: swap encryption: per-page tracking seems overengineered
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.
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.
Home |
Main Index |
Thread Index |
Old Index