linux-kernel - [PATCH 3/3] wireguard: device: clear keys on VM fork

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220301231038.530897-4-Jason@zx2c4.com>
Date:   Wed,  2 Mar 2022 00:10:38 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        netdev@...r.kernel.org, Alexander Graf <graf@...zon.com>,
        Jann Horn <jannh@...gle.com>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Theodore Ts'o <tytso@....edu>, Jakub Kicinski <kuba@...nel.org>
Subject: [PATCH 3/3] wireguard: device: clear keys on VM fork

When a virtual machine forks, it's important that WireGuard clear
existing sessions so that different plaintext is not transmitted using
the same key+nonce, which can result in catastrophic cryptographic
failure. To accomplish this, we simply hook into the newly added vmfork
notifier, which can use the same notification function we're already
using for PM notifications.

As a bonus, it turns out that, like the vmfork registration function,
the PM registration function is stubbed out when CONFIG_PM_SLEEP is not
set, so we can actually just remove the maze of ifdefs, which makes it
really quite clean to support both notifiers at once.

Cc: Dominik Brodowski <linux@...inikbrodowski.net>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Theodore Ts'o <tytso@....edu>
Cc: Jakub Kicinski <kuba@...nel.org>
Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
---
Hi Jakub,

I wasn't planning on sending other WireGuard changes to net-next this
cycle, and this one here depends on previous things in my random.git
tree. Is it okay with you if I take this through my tree rather than
net-next? Alternatively, I could send it through net after rc1 if you'd
prefer that. Or we could just wait for 5.19, but that seems a long way's
off.

Thanks,
Jason

 drivers/net/wireguard/device.c | 27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index a46067c38bf5..22cc27c221f8 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -59,7 +59,10 @@ static int wg_open(struct net_device *dev)
 	return ret;
 }
 
-#ifdef CONFIG_PM_SLEEP
+static int wg_pm_notification(struct notifier_block *nb, unsigned long action, void *data);
+static struct notifier_block pm_notifier = { .notifier_call = wg_pm_notification };
+static struct notifier_block vm_notifier = { .notifier_call = wg_pm_notification };
+
 static int wg_pm_notification(struct notifier_block *nb, unsigned long action,
 			      void *data)
 {
@@ -70,10 +73,10 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action,
 	 * its normal operation rather than as a somewhat rare event, then we
 	 * don't actually want to clear keys.
 	 */
-	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
+	if (nb == &pm_notifier && (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID)))
 		return 0;
 
-	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
+	if (nb == &pm_notifier && action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
 		return 0;
 
 	rtnl_lock();
@@ -91,9 +94,6 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action,
 	return 0;
 }
 
-static struct notifier_block pm_notifier = { .notifier_call = wg_pm_notification };
-#endif
-
 static int wg_stop(struct net_device *dev)
 {
 	struct wg_device *wg = netdev_priv(dev);
@@ -424,16 +424,18 @@ int __init wg_device_init(void)
 {
 	int ret;
 
-#ifdef CONFIG_PM_SLEEP
 	ret = register_pm_notifier(&pm_notifier);
 	if (ret)
 		return ret;
-#endif
 
-	ret = register_pernet_device(&pernet_ops);
+	ret = register_random_vmfork_notifier(&vm_notifier);
 	if (ret)
 		goto error_pm;
 
+	ret = register_pernet_device(&pernet_ops);
+	if (ret)
+		goto error_vm;
+
 	ret = rtnl_link_register(&link_ops);
 	if (ret)
 		goto error_pernet;
@@ -442,10 +444,10 @@ int __init wg_device_init(void)
 
 error_pernet:
 	unregister_pernet_device(&pernet_ops);
+error_vm:
+	unregister_random_vmfork_notifier(&vm_notifier);
 error_pm:
-#ifdef CONFIG_PM_SLEEP
 	unregister_pm_notifier(&pm_notifier);
-#endif
 	return ret;
 }
 
@@ -453,8 +455,7 @@ void wg_device_uninit(void)
 {
 	rtnl_link_unregister(&link_ops);
 	unregister_pernet_device(&pernet_ops);
-#ifdef CONFIG_PM_SLEEP
+	unregister_random_vmfork_notifier(&vm_notifier);
 	unregister_pm_notifier(&pm_notifier);
-#endif
 	rcu_barrier();
 }
-- 
2.35.1