NetBSD Problem Report #60084
From www@netbsd.org Sun Mar 15 03:36:54 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.netbsd.org", Issuer "R12" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 63D291A9244
for <gnats-bugs@gnats.NetBSD.org>; Sun, 15 Mar 2026 03:36:54 +0000 (UTC)
Message-Id: <20260315033653.6651B1A9246@mollari.NetBSD.org>
Date: Sun, 15 Mar 2026 03:36:53 +0000 (UTC)
From: imuwoto@gmail.com
Reply-To: imuwoto@gmail.com
To: gnats-bugs@NetBSD.org
Subject: swap encryption: per-page tracking seems overengineered
X-Send-Pr-Version: www-1.0
X-From4GNATS: "imuwoto@gmail.com via gnats" <gnats-admin@NetBSD.org>
>Number: 60084
>Notify-List: riastradh@NetBSD.org
>Category: kern
>Synopsis: swap encryption: per-page tracking seems overengineered
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Mar 15 03:40:00 +0000 2026
>Last-Modified: Sat Jun 27 15:00:14 +0000 2026
>Originator: YAMAMOTO Takashi
>Release: -current
>Organization:
>Environment:
amd64
>Description:
swap encryption maintains a bitmap to track per-page encryption
status. it's wasteful and unnecessarily complicate the implementation.
it would be simpler to let user decide it at swapon time.
after all, i suppose a user would either wants to encrypt all of the
swap, or none of them. not any middle of them.
that way the encryption key can be generated at swapon time too.
>How-To-Repeat:
code inspection
>Fix:
my suggestions:
* reject attempts to change vm.swap_encrypt sysctl if swap is configured.
* remove swd_encmap
* generate key on swapon
>Release-Note:
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: imuwoto@gmail.com
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Sun, 15 Mar 2026 04:36:54 +0000
[resent via correct MTA for @NetBSD.org and with correct magic subject
line, apologies for duplicates]
> Date: Sun, 15 Mar 2026 03:36:53 +0000 (UTC)
> From: imuwoto@gmail.com
>
> swap encryption maintains a bitmap to track per-page encryption
> status. it's wasteful and unnecessarily complicate the implementation.
> it would be simpler to let user decide it at swapon time.
> after all, i suppose a user would either wants to encrypt all of the
> swap, or none of them. not any middle of them.
The most important part is to make it seamless for users, so it's not
some bizarro hardening knob that only bizarro security nerds will mess
around with (like swap-on-cgd or cgdroot-ramdisk).
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.
I considered implementing a per-device flag for swapon, but that would
entail changes to userland, questions about compat, and generally a
more complicated interaction with users than the sysctl setting. So I
went with a simpler-impact change at a slightly higher cost to the
internal implementation.
I wouldn't object to adding a per-device flag but I didn't want to
think about all the parts that have to fit together to make it work --
and make sure it happens by default, without users having to think
about it.
Perhaps, rather than a flag for swapon, each swap device should simply
record the value of vm.swap_encrypt when it is configured -- that way,
a whole swap device at a time will be ciphertext or plaintext, but
there's no other userland interface changes, and it still doesn't take
a kernel rebuild or reboot to make a change.
However, this would mean that after you set vm.swap_encrypt=1, you are
_not_ guaranteed that subsequent swapped pages will be encrypted; you
are only guaranteed that if you _also_ do a swapoff/swapon cycle.
That's _probably_ fine, as long as we update the sysctl(7) man page
(and hope everyone who read it before reads it again), but it's a
little less seamless and could cause security-destroying confusion.
> that way the encryption key can be generated at swapon time too.
Deferring key generation until the latest moment before it is actually
needed helps to maximize the amount of data fed into the entropy pool
before generating a key, for the benefit of machines without HWRNG.
Since key generation doesn't allocate any memory, what is the
motivation to do it earlier? Saving one byte of memory per swap
device that records whether the key has been generated? We could
probably achieve the same by reordering some struct swapdev members.
From: "YAMAMOTO Takashi" <yamt@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60084 CVS commit: src/sys/uvm
Date: Sun, 15 Mar 2026 05:05:51 +0000
Module Name: src
Committed By: yamt
Date: Sun Mar 15 05:05:51 UTC 2026
Modified Files:
src/sys/uvm: uvm_swap.c
Log Message:
swap_on: add a comment about the motivation to defer key generation
the original text from Taylor R Campbell, in PR/60084.
To generate a diff of this commit:
cvs rdiff -u -r1.215 -r1.216 src/sys/uvm/uvm_swap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Takashi Yamamoto <imuwoto2@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
imuwoto@gmail.com, riastradh@netbsd.org
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Sun, 15 Mar 2026 14:05:57 +0900
hi,
On Sun, Mar 15, 2026 at 1:40=E2=80=AFPM Taylor R Campbell via gnats
<gnats-admin@netbsd.org> wrote:
>
> The following reply was made to PR kern/60084; it has been noted by GNATS=
.
>
> From: Taylor R Campbell <riastradh@NetBSD.org>
> To: imuwoto@gmail.com
> Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
> Subject: Re: kern/60084: swap encryption: per-page tracking seems overeng=
ineered
> Date: Sun, 15 Mar 2026 04:36:54 +0000
>
> [resent via correct MTA for @NetBSD.org and with correct magic subject
> line, apologies for duplicates]
>
> > Date: Sun, 15 Mar 2026 03:36:53 +0000 (UTC)
> > From: imuwoto@gmail.com
> >
> > swap encryption maintains a bitmap to track per-page encryption
> > status. it's wasteful and unnecessarily complicate the implementation.
> > it would be simpler to let user decide it at swapon time.
> > after all, i suppose a user would either wants to encrypt all of the
> > swap, or none of them. not any middle of them.
>
> The most important part is to make it seamless for users, so it's not
> some bizarro hardening knob that only bizarro security nerds will mess
> around with (like swap-on-cgd or cgdroot-ramdisk).
>
> 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.
> I considered implementing a per-device flag for swapon, but that would
> entail changes to userland, questions about compat, and generally a
> more complicated interaction with users than the sysctl setting. So I
> went with a simpler-impact change at a slightly higher cost to the
> internal implementation.
>
> I wouldn't object to adding a per-device flag but I didn't want to
> think about all the parts that have to fit together to make it work --
> and make sure it happens by default, without users having to think
> about it.
>
> Perhaps, rather than a flag for swapon, each swap device should simply
> record the value of vm.swap_encrypt when it is configured -- that way,
> a whole swap device at a time will be ciphertext or plaintext, but
> there's no other userland interface changes, and it still doesn't take
> a kernel rebuild or reboot to make a change.
my proposal is just a global knob (vm.swap_encrypt) which can't be
changed if any swap devices are configured.
> However, this would mean that after you set vm.swap_encrypt=3D1, you are
> _not_ guaranteed that subsequent swapped pages will be encrypted; you
> are only guaranteed that if you _also_ do a swapoff/swapon cycle.
> That's _probably_ fine, as long as we update the sysctl(7) man page
> (and hope everyone who read it before reads it again), but it's a
> little less seamless and could cause security-destroying confusion.
with the current machinery, if a user wants to ensure all swaps are encrypt=
ed,
he has to ensure no swap slots are used when he turned vm.swap_encrypt on.
it's essentially the same as a swapoff/on cycle.
>
> > that way the encryption key can be generated at swapon time too.
>
> Deferring key generation until the latest moment before it is actually
> needed helps to maximize the amount of data fed into the entropy pool
> before generating a key, for the benefit of machines without HWRNG.
it makes sense. i added a comment in the code.
> Since key generation doesn't allocate any memory, what is the
> motivation to do it earlier? Saving one byte of memory per swap
> device that records whether the key has been generated? We could
> probably achieve the same by reordering some struct swapdev members.
i wanted to simplify swap io logic.
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Takashi Yamamoto <imuwoto2@gmail.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, imuwoto@gmail.com
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>
>=20
> On Sun, Mar 15, 2026 at 1:40=E2=80=AFPM Taylor R Campbell via gnats
> <gnats-admin@netbsd.org> 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.
From: Takashi Yamamoto <imuwoto2@gmail.com>
To: Taylor R Campbell <riastradh@netbsd.org>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, imuwoto@gmail.com
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>
> >
> > On Sun, Mar 15, 2026 at 1:40=E2=80=AFPM Taylor R Campbell via gnats
> > <gnats-admin@netbsd.org> 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.
From: Takashi Yamamoto <imuwoto2@gmail.com>
To: Taylor R Campbell <riastradh@netbsd.org>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, imuwoto@gmail.com
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=
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>
> > >
> > > On Sun, Mar 15, 2026 at 1:40=E2=80=AFPM Taylor R Campbell via gnats
> > > <gnats-admin@netbsd.org> 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.
From: Takashi Yamamoto <imuwoto2@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
imuwoto@gmail.com, riastradh@netbsd.org
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Tue, 17 Mar 2026 17:31:33 +0900
--0000000000008297cd064d342a06
Content-Type: text/plain; charset="UTF-8"
hi,
> my proposal is just a global knob (vm.swap_encrypt) which can't be
> changed if any swap devices are configured.
here's a patch.
identical patch is available at
https://github.com/yamt/netbsd-src/commit/471d17d6708677e778c2e6d82afd5d6041863f10
--0000000000008297cd064d342a06
Content-Type: application/octet-stream; name="a.diff"
Content-Disposition: attachment; filename="a.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_mmucqn2i0>
X-Attachment-Id: f_mmucqn2i0
Y29tbWl0IGU4ZDZjNmVkOGQxMzU1Y2FiYWZjMGY1NjFiM2UyN2RjNWI0OWE4M2YKQXV0aG9yOiBZ
QU1BTU9UTyBUYWthc2hpIDxpbXV3b3RvQGdtYWlsLmNvbT4KRGF0ZTogICBTdW4gTWFyIDE1IDA1
OjQ5OjE5IDIwMjYgKzAwMDAKCiAgICBzaW1wbGlmeSBzd2FwIGVuY3J5cHRpb24gYSBiaXQKICAg
IAogICAgKiBkaXNhbGxvdyBjaGFuZ2VzIG9mIHZtLnN3YXBfZW5jcnlwdCBzeXNjdGwgd2hlbiBh
bnkgc3dhcAogICAgICBpcyBjb25maWd1cmVkLiAgbm90ZTogdGhpcyBkb2Vzbid0IGFmZmVjdCB0
aGUgYWJpbGl0eSB0bwogICAgICBzZXQgaXQgaW4gL2V0Yy9zeXNjdGwuY29uZiBiZWNhdXNlIC9l
dGMvcmMuZC9zeXNjdGwgaXMKICAgICAgZXhlY3V0ZWQgYmVmb3JlIC9ldGMvcmMuZC9zd2FwMS4K
ICAgIAogICAgKiByZXRpcmUgcGVyLXBhZ2UgZW50cnlwdGlvbiB0cmFja2luZy4gKHN3ZF9lbmNt
YXApCiAgICAgIGZyb20gbm93IG9uLCB0aGUgd2hvbGUgc3dhcCBpcyBlbmNyeXB0ZWQgb3Igbm90
LgogICAgCiAgICBQUi82MDA4NAogICAgaHR0cHM6Ly9nbmF0cy5uZXRic2Qub3JnLzYwMDg0Cgpk
aWZmIC0tZ2l0IGEvc3lzL3V2bS91dm1fc3dhcC5jIGIvc3lzL3V2bS91dm1fc3dhcC5jCmluZGV4
IDMxYWM2MDI3ZTQ2My4uNjM0YWFkYmYwZjhkIDEwMDY0NAotLS0gYS9zeXMvdXZtL3V2bV9zd2Fw
LmMKKysrIGIvc3lzL3V2bS91dm1fc3dhcC5jCkBAIC0xNDQsNyArMTQ0LDYgQEAgc3RydWN0IHN3
YXBkZXYgewogCXN0cnVjdCB2bm9kZQkJKnN3ZF92cDsJLyogYmFja2luZyB2bm9kZSAqLwogCVRB
SUxRX0VOVFJZKHN3YXBkZXYpCXN3ZF9uZXh0OwkvKiBwcmlvcml0eSB0YWlscSAqLwogCi0Jdm9s
YXRpbGUgdWludDMyX3QJKnN3ZF9lbmNtYXA7CS8qIGJpdG1hcCBvZiBlbmNyeXB0ZWQgc2xvdHMg
Ki8KIAlzdHJ1Y3QgYWVzZW5jCQlzd2RfZW5ja2V5OwkvKiBBRVMga2V5IGV4cGFuZGVkIGZvciBl
bmMgKi8KIAlzdHJ1Y3QgYWVzZGVjCQlzd2RfZGVja2V5OwkvKiBBRVMga2V5IGV4cGFuZGVkIGZv
ciBkZWMgKi8KIAlib29sCQkJc3dkX2VuY2luaXQ7CS8qIHRydWUgaWYga2V5cyBpbml0aWFsaXpl
ZCAqLwpAQCAtMjIwLDE5ICsyMTksNiBAQCBzdGF0aWMgdm9pZCB1dm1fc3dhcF9nZW5rZXkoc3Ry
dWN0IHN3YXBkZXYgKik7CiBzdGF0aWMgdm9pZCB1dm1fc3dhcF9lbmNyeXB0cGFnZShzdHJ1Y3Qg
c3dhcGRldiAqLCB2b2lkICosIGludCk7CiBzdGF0aWMgdm9pZCB1dm1fc3dhcF9kZWNyeXB0cGFn
ZShzdHJ1Y3Qgc3dhcGRldiAqLCB2b2lkICosIGludCk7CiAKLXN0YXRpYyBzaXplX3QKLWVuY21h
cF9zaXplKHNpemVfdCBucGFnZXMpCi17Ci0Jc3RydWN0IHN3YXBkZXYgKnNkcDsKLQljb25zdCBz
aXplX3QgYnl0ZXNwZXJ3b3JkID0gc2l6ZW9mKHNkcC0+c3dkX2VuY21hcFswXSk7Ci0JY29uc3Qg
c2l6ZV90IGJpdHNwZXJ3b3JkID0gTkJCWSAqIGJ5dGVzcGVyd29yZDsKLQljb25zdCBzaXplX3Qg
bmJpdHMgPSBucGFnZXM7IC8qIG9uZSBiaXQgZm9yIGVhY2ggcGFnZSAqLwotCWNvbnN0IHNpemVf
dCBud29yZHMgPSBob3dtYW55KG5iaXRzLCBiaXRzcGVyd29yZCk7Ci0JY29uc3Qgc2l6ZV90IG5i
eXRlcyA9IG53b3JkcyAqIGJ5dGVzcGVyd29yZDsKLQotCXJldHVybiBuYnl0ZXM7Ci19Ci0KIC8q
CiAgKiB1dm1fc3dhcF9pbml0OiBpbml0IHRoZSBzd2FwIHN5c3RlbSBkYXRhIHN0cnVjdHVyZXMg
YW5kIGxvY2tzCiAgKgpAQCAtMTA1MSwxNCArMTAzNywxMiBAQCBzd2FwX29uKHN0cnVjdCBsd3Ag
KmwsIHN0cnVjdCBzd2FwZGV2ICpzZHApCiAJYmxpc3RfZnJlZShzZHAtPnN3ZF9ibGlzdCwgYWRk
ciwgc2l6ZSk7CiAKIAkvKgotCSAqIGFsbG9jYXRlIHNwYWNlIHRvIGZvciBzd2FwIGVuY3J5cHRp
b24gc3RhdGUgYW5kIG1hcmsgdGhlCi0JICoga2V5cyB1bmluaXRpYWxpemVkIHNvIHdlIGdlbmVy
YXRlIHRoZW0gbGF6aWx5LgorCSAqIG1hcmsgdGhlIGtleXMgdW5pbml0aWFsaXplZCBzbyB3ZSBn
ZW5lcmF0ZSB0aGVtIGxhemlseS4KIAkgKgogCSAqIHdlIGRlZmVyIHRoZSBrZXkgZ2VuZXJhdGlv
biB0byBoZWxwIHRvIG1heGltaXplIHRoZSBhbW91bnQKIAkgKiBvZiBkYXRhIGZlZCBpbnRvIHRo
ZSBlbnRyb3B5IHBvb2wgYmVmb3JlIGdlbmVyYXRpbmcgYSBrZXksCiAJICogZm9yIHRoZSBiZW5l
Zml0IG9mIG1hY2hpbmVzIHdpdGhvdXQgSFdSTkcuCiAJICovCi0Jc2RwLT5zd2RfZW5jbWFwID0g
a21lbV96YWxsb2MoZW5jbWFwX3NpemUobnBhZ2VzKSwgS01fU0xFRVApOwogCXNkcC0+c3dkX2Vu
Y2luaXQgPSBmYWxzZTsKIAogCS8qCkBAIC0xMjQwLDggKzEyMjQsNiBAQCBzd2FwX29mZihzdHJ1
Y3QgbHdwICpsLCBzdHJ1Y3Qgc3dhcGRldiAqc2RwKQogCXZtZW1fZnJlZShzd2FwbWFwLCBzZHAt
PnN3ZF9kcnVtb2Zmc2V0LCBzZHAtPnN3ZF9kcnVtc2l6ZSk7CiAJYmxpc3RfZGVzdHJveShzZHAt
PnN3ZF9ibGlzdCk7CiAJYnVmcV9mcmVlKHNkcC0+c3dkX3RhYik7Ci0Ja21lbV9mcmVlKF9fVU5W
T0xBVElMRShzZHAtPnN3ZF9lbmNtYXApLAotCSAgICBlbmNtYXBfc2l6ZShzZHAtPnN3ZF9kcnVt
c2l6ZSkpOwogCWV4cGxpY2l0X21lbXNldCgmc2RwLT5zd2RfZW5ja2V5LCAwLCBzaXplb2Ygc2Rw
LT5zd2RfZW5ja2V5KTsKIAlleHBsaWNpdF9tZW1zZXQoJnNkcC0+c3dkX2RlY2tleSwgMCwgc2l6
ZW9mIHNkcC0+c3dkX2RlY2tleSk7CiAJbXV0ZXhfZGVzdHJveSgmc2RwLT5zd2RfbG9jayk7CkBA
IC0xOTI3LDcgKzE5MDksNyBAQCB1dm1fc3dhcF9pbyhzdHJ1Y3Qgdm1fcGFnZSAqKnBwcywgaW50
IHN0YXJ0c2xvdCwgaW50IG5wYWdlcywgaW50IGZsYWdzKQogCSAqIGVuY3J5cHQgd3JpdGVzIGlu
IHBsYWNlIGlmIHJlcXVlc3RlZAogCSAqLwogCi0JaWYgKHdyaXRlKSBkbyB7CisJaWYgKHdyaXRl
ICYmIHN3YXBfZW5jcnlwdCkgewogCQlzdHJ1Y3Qgc3dhcGRldiAqc2RwOwogCQlpbnQgaTsKIApA
QCAtMTk1MiwxMCArMTkzNCw2IEBAIHV2bV9zd2FwX2lvKHN0cnVjdCB2bV9wYWdlICoqcHBzLCBp
bnQgc3RhcnRzbG90LCBpbnQgbnBhZ2VzLCBpbnQgZmxhZ3MpCiAJCW11dGV4X2VudGVyKCZ1dm1f
c3dhcF9kYXRhX2xvY2spOwogCQlzZHAgPSBzd2FwZHJ1bV9nZXRzZHAoc3RhcnRzbG90KTsKIAkJ
aWYgKCFzZHAtPnN3ZF9lbmNpbml0KSB7Ci0JCQlpZiAoIXN3YXBfZW5jcnlwdCkgewotCQkJCW11
dGV4X2V4aXQoJnV2bV9zd2FwX2RhdGFfbG9jayk7Ci0JCQkJYnJlYWs7Ci0JCQl9CiAJCQl1dm1f
c3dhcF9nZW5rZXkoc2RwKTsKIAkJfQogCQlLQVNTRVJUKHNkcC0+c3dkX2VuY2luaXQpOwpAQCAt
MTk2NywxOCArMTk0NSwxMCBAQCB1dm1fc3dhcF9pbyhzdHJ1Y3Qgdm1fcGFnZSAqKnBwcywgaW50
IHN0YXJ0c2xvdCwgaW50IG5wYWdlcywgaW50IGZsYWdzKQogCQkJS0FTU0VSVChzID49IHNkcC0+
c3dkX2RydW1vZmZzZXQpOwogCQkJcyAtPSBzZHAtPnN3ZF9kcnVtb2Zmc2V0OwogCQkJS0FTU0VS
VChzIDwgc2RwLT5zd2RfZHJ1bXNpemUpOwotCi0JCQlpZiAoc3dhcF9lbmNyeXB0KSB7Ci0JCQkJ
dXZtX3N3YXBfZW5jcnlwdHBhZ2Uoc2RwLAotCQkJCSAgICAodm9pZCAqKShrdmEgKyAodnNpemVf
dClpKlBBR0VfU0laRSksIHMpOwotCQkJCWF0b21pY19vcl8zMigmc2RwLT5zd2RfZW5jbWFwW3Mv
MzJdLAotCQkJCSAgICBfX0JJVChzJTMyKSk7Ci0JCQl9IGVsc2UgewotCQkJCWF0b21pY19hbmRf
MzIoJnNkcC0+c3dkX2VuY21hcFtzLzMyXSwKLQkJCQkgICAgfl9fQklUKHMlMzIpKTsKLQkJCX0K
KwkJCXV2bV9zd2FwX2VuY3J5cHRwYWdlKHNkcCwKKwkJCSAgICAodm9pZCAqKShrdmEgKyAodnNp
emVfdClpKlBBR0VfU0laRSksIHMpOwogCQl9Ci0JfSB3aGlsZSAoMCk7CisJfQogCiAJLyoKIAkg
KiBmaWxsIGluIHRoZSBicC9zYnAuICAgd2UgY3VycmVudGx5IHJvdXRlIG91ciBpL28gdGhyb3Vn
aApAQCAtMjA0OCw3ICsyMDE4LDcgQEAgdXZtX3N3YXBfaW8oc3RydWN0IHZtX3BhZ2UgKipwcHMs
IGludCBzdGFydHNsb3QsIGludCBucGFnZXMsIGludCBmbGFncykKIAkgKiBkZWNyeXB0IHJlYWRz
IGluIHBsYWNlIGlmIG5lZWRlZAogCSAqLwogCi0JaWYgKCF3cml0ZSkgZG8geworCWlmICghd3Jp
dGUgJiYgc3dhcF9lbmNyeXB0KSB7CiAJCXN0cnVjdCBzd2FwZGV2ICpzZHA7CiAJCWJvb2wgZW5j
aW5pdDsKIAkJaW50IGk7CkBAIC0yMDY1LDI2ICsyMDM1LDIxIEBAIHV2bV9zd2FwX2lvKHN0cnVj
dCB2bV9wYWdlICoqcHBzLCBpbnQgc3RhcnRzbG90LCBpbnQgbnBhZ2VzLCBpbnQgZmxhZ3MpCiAJ
CWVuY2luaXQgPSBzZHAtPnN3ZF9lbmNpbml0OwogCQltdXRleF9leGl0KCZ1dm1fc3dhcF9kYXRh
X2xvY2spOwogCi0JCWlmICghZW5jaW5pdCkKLQkJCS8qCi0JCQkgKiBJZiB0aGVyZSdzIG5vIGVu
Y3J5cHRpb24ga2V5LCB0aGVyZSdzIG5vIHdheQotCQkJICogYW55IG9mIHRoZXNlIHNsb3RzIGNh
biBiZSBlbmNyeXB0ZWQsIHNvCi0JCQkgKiBub3RoaW5nIHRvIGRvIGhlcmUuCi0JCQkgKi8KLQkJ
CWJyZWFrOworCQkvKgorCQkgKiAhZW5jaW5pdCBoZXJlIG1lYW5zIHdlIGFyZSBzd2FwcGluZyBp
biBhIHBhZ2Ugd2hpY2gKKwkJICogaGFzIG5ldmVuIGJlZW4gc3dhcHBlZCBvdXQuIGl0IHNob3Vs
ZCBiZSBhIGJ1Zy4KKwkJICovCisJCUtBU1NFUlQoZW5jaW5pdCk7CiAJCWZvciAoaSA9IDA7IGkg
PCBucGFnZXM7IGkrKykgewogCQkJaW50IHMgPSBzdGFydHNsb3QgKyBpOwogCQkJS0RBU1NFUlQo
c3dhcGRydW1fc2RwX2lzKHMsIHNkcCkpOwogCQkJS0FTU0VSVChzID49IHNkcC0+c3dkX2RydW1v
ZmZzZXQpOwogCQkJcyAtPSBzZHAtPnN3ZF9kcnVtb2Zmc2V0OwogCQkJS0FTU0VSVChzIDwgc2Rw
LT5zd2RfZHJ1bXNpemUpOwotCQkJaWYgKChhdG9taWNfbG9hZF9yZWxheGVkKCZzZHAtPnN3ZF9l
bmNtYXBbcy8zMl0pICYKLQkJCQlfX0JJVChzJTMyKSkgPT0gMCkKLQkJCQljb250aW51ZTsKIAkJ
CXV2bV9zd2FwX2RlY3J5cHRwYWdlKHNkcCwKIAkJCSAgICAodm9pZCAqKShrdmEgKyAodnNpemVf
dClpKlBBR0VfU0laRSksIHMpOwogCQl9Ci0JfSB3aGlsZSAoMCk7CisJfQogb3V0OgogCS8qCiAJ
ICoga2lsbCB0aGUgcGFnZXIgbWFwcGluZwpAQCAtMjE3MSwxMiArMjEzNiw0NCBAQCB1dm1fc3dh
cF9kZWNyeXB0cGFnZShzdHJ1Y3Qgc3dhcGRldiAqc2RwLCB2b2lkICprdmEsIGludCBzbG90KQog
CWV4cGxpY2l0X21lbXNldCgmaXYsIDAsIHNpemVvZiBpdik7CiB9CiAKK3N0YXRpYyBpbnQKK3N5
c2N0bF9rZXJuX3V2bV9zd2FwX2VuY3J5dHAoU1lTQ1RMRk5fQVJHUykKK3sKKwlzdHJ1Y3Qgc3lz
Y3Rsbm9kZSBub2RlOworCWludCBzd2FwX2VuY3J5cHQgPSB1dm1fc3dhcF9lbmNyeXB0OworCWlu
dCBlcnJvcjsKKworCW5vZGUgPSAqcm5vZGU7CisJbm9kZS5zeXNjdGxfZGF0YSA9ICZzd2FwX2Vu
Y3J5cHQ7CisJZXJyb3IgPSBzeXNjdGxfbG9va3VwKFNZU0NUTEZOX0NBTEwoJm5vZGUpKTsKKwlp
ZiAoZXJyb3IgIT0gMCB8fCBuZXdwID09IE5VTEwpIHsKKwkJcmV0dXJuIGVycm9yOworCX0KKwkv
KgorCSAqIGFsbG93IGEgY2hhbmdlIG9ubHkgd2hlbiBubyBzd2FwIGlzIGNvbmZpZ3VyZWQgdG8g
ZW5zdXJlCisJICogdGhhdCB1dm1fc3dhcF9lbmNyeXB0IGlzIGEgY29uc3RhbnQgZnJvbSB0aGUg
UE9WIG9mCisJICogYW55IHN3YXAgZGV2aWNlcy4KKwkgKi8KKwllcnJvciA9IDA7CisJbXV0ZXhf
ZW50ZXIoJnV2bV9zd2FwX2RhdGFfbG9jayk7CisJaWYgKHV2bV9zd2FwX2VuY3J5cHQgIT0gc3dh
cF9lbmNyeXB0KSB7CisJCWlmIChMSVNUX0VNUFRZKCZzd2FwX3ByaW9yaXR5KSkgeworCQkJdXZt
X3N3YXBfZW5jcnlwdCA9IHN3YXBfZW5jcnlwdDsKKwkJfSBlbHNlIHsKKwkJCWVycm9yID0gRUJV
U1k7CisJCX0KKwl9CisJbXV0ZXhfZXhpdCgmdXZtX3N3YXBfZGF0YV9sb2NrKTsKKworCXJldHVy
biBlcnJvcjsKK30KKwogU1lTQ1RMX1NFVFVQKHN5c2N0bF91dm1zd2FwX3NldHVwLCAic3lzY3Rs
IHV2bXN3YXAgc2V0dXAiKQogewogCiAJc3lzY3RsX2NyZWF0ZXYoY2xvZywgMCwgTlVMTCwgTlVM
TCwKIAkgICAgQ1RMRkxBR19QRVJNQU5FTlR8Q1RMRkxBR19SRUFEV1JJVEUsIENUTFRZUEVfQk9P
TCwgInN3YXBfZW5jcnlwdCIsCiAJICAgIFNZU0NUTF9ERVNDUigiRW5jcnlwdCBkYXRhIHdoZW4g
c3dhcHBlZCBvdXQgdG8gZGlzayIpLAotCSAgICBOVUxMLCAwLCAmdXZtX3N3YXBfZW5jcnlwdCwg
MCwKKwkgICAgc3lzY3RsX2tlcm5fdXZtX3N3YXBfZW5jcnl0cCwgMCwgTlVMTCwgMCwKIAkgICAg
Q1RMX1ZNLCBDVExfQ1JFQVRFLCBDVExfRU9MKTsKIH0K
--0000000000008297cd064d342a06--
From: Takashi YAMAMOTO <yamt9999@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
imuwoto@gmail.com, riastradh@netbsd.org
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Wed, 25 Mar 2026 13:11:01 +0900
> > my proposal is just a global knob (vm.swap_encrypt) which can't be
> > changed if any swap devices are configured.
>
> here's a patch.
> identical patch is available at
> https://github.com/yamt/netbsd-src/commit/471d17d6708677e778c2e6d82afd5d6041863f10
Taylor, is this acceptable for you?
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Takashi YAMAMOTO <yamt9999@gmail.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, imuwoto@gmail.com
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Thu, 26 Mar 2026 03:36:21 +0000
> Date: Wed, 25 Mar 2026 13:11:01 +0900
> From: Takashi YAMAMOTO <yamt9999@gmail.com>
>=20
> > > my proposal is just a global knob (vm.swap_encrypt) which can't be
> > > changed if any swap devices are configured.
> >
> > here's a patch.
> > identical patch is available at
> > https://github.com/yamt/netbsd-src/commit/471d17d6708677e778c2e6d82afd=
5d6041863f10
>=20
> Taylor, is this acceptable for you?
Go for it! But please make sure to test that things work when you set
them up in /etc/sysctl.conf and /etc/fstab, when the vm.swap_encrypt
setting doesn't match the kernel default.
From: Takashi YAMAMOTO <yamt9999@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
imuwoto@gmail.com, riastradh@netbsd.org
Subject: Re: kern/60084: swap encryption: per-page tracking seems overengineered
Date: Fri, 27 Mar 2026 12:40:44 +0900
On Thu, Mar 26, 2026 at 12:40=E2=80=AFPM Taylor R Campbell via gnats
<gnats-admin@netbsd.org> wrote:
>
> The following reply was made to PR kern/60084; it has been noted by GNATS=
.
>
> From: Taylor R Campbell <riastradh@NetBSD.org>
> To: Takashi YAMAMOTO <yamt9999@gmail.com>
> Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
> gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, imuwoto@gmail.com
> Subject: Re: kern/60084: swap encryption: per-page tracking seems overeng=
ineered
> Date: Thu, 26 Mar 2026 03:36:21 +0000
>
> > Date: Wed, 25 Mar 2026 13:11:01 +0900
> > From: Takashi YAMAMOTO <yamt9999@gmail.com>
> >=3D20
> > > > my proposal is just a global knob (vm.swap_encrypt) which can't b=
e
> > > > changed if any swap devices are configured.
> > >
> > > here's a patch.
> > > identical patch is available at
> > > https://github.com/yamt/netbsd-src/commit/471d17d6708677e778c2e6d82=
afd=3D
> 5d6041863f10
> >=3D20
> > Taylor, is this acceptable for you?
>
> Go for it! But please make sure to test that things work when you set
> them up in /etc/sysctl.conf and /etc/fstab, when the vm.swap_encrypt
> setting doesn't match the kernel default.
my vm has a swap in /etc/fstab and vm.swap_encrypt=3D0 in
/etc/sysctl.conf to workaround the bugs.
it seems working as expected.
From: "YAMAMOTO Takashi" <yamt@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60084 CVS commit: src/sys/uvm
Date: Fri, 27 Mar 2026 07:13:06 +0000
Module Name: src
Committed By: yamt
Date: Fri Mar 27 07:13:06 UTC 2026
Modified Files:
src/sys/uvm: uvm_swap.c
Log Message:
simplify swap encryption a bit
* disallow changes of vm.swap_encrypt sysctl when any swap
is configured. note: this doesn't affect the ability to
set it in /etc/sysctl.conf because /etc/rc.d/sysctl is
executed before /etc/rc.d/swap1.
* retire per-page encryption tracking. (swd_encmap)
from now on, the whole swap is encrypted or not.
PR/60084
https://gnats.netbsd.org/60084
To generate a diff of this commit:
cvs rdiff -u -r1.219 -r1.220 src/sys/uvm/uvm_swap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60084 CVS commit: src/sys/uvm
Date: Sat, 27 Jun 2026 14:56:29 +0000
Module Name: src
Committed By: riastradh
Date: Sat Jun 27 14:56:29 UTC 2026
Modified Files:
src/sys/uvm: uvm_swap.c
Log Message:
uvm(9): Fix comments on swap encryption and tidy various whitespace.
No functional change intended: comments and whitespace only.
Cleanup after various fixes for:
PR kern/60082: swap encryption corrupt data
PR kern/60083: swap encryption break /dev/drum
PR kern/60084: swap encryption: per-page tracking seems overengineered
To generate a diff of this commit:
cvs rdiff -u -r1.233 -r1.234 src/sys/uvm/uvm_swap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home