| Message ID | 20220301231038.530897-4-Jason@zx2c4.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | random: wire up in-kernel virtual machine fork notifications | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Guessing tree name failed - patch did not apply |
On Wed, 2 Mar 2022 00:10:38 +0100 Jason A. Donenfeld wrote: > 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? Yup, Acked-by: Jakub Kicinski <kuba@kernel.org>
On Wed, Mar 02, 2022 at 12:10:38AM +0100, Jason A. Donenfeld wrote: > 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@dominikbrodowski.net> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Theodore Ts'o <tytso@mit.edu> > Cc: Jakub Kicinski <kuba@kernel.org> > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Catastrophic cryptographic failure sounds bad :( So in another thread we discussed that there's a race with this approach, and we don't know how big it is. Question is how expensive it would be to fix it properly checking for fork after every use of key+nonce and before transmitting it. I did a quick microbenchmark and it did not seem too bad - care posting some numbers? > --- > 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 > >
Hi Michael, On Wed, Mar 2, 2022 at 9:36 AM Michael S. Tsirkin <mst@redhat.com> wrote: > Catastrophic cryptographic failure sounds bad :( > So in another thread we discussed that there's a race with this > approach, and we don't know how big it is. Question is how expensive > it would be to fix it properly checking for fork after every use of > key+nonce and before transmitting it. I did a quick microbenchmark > and it did not seem too bad - care posting some numbers? I followed up in that thread, which is a larger one, so it might be easiest to keep discussion there. My response to you here is the same as it was over there. :) https://lore.kernel.org/lkml/CAHmME9pf-bjnZuweoLqoFEmPy1OK7ogEgGEAva1T8uVTufhCuw@mail.gmail.com/ Jason
On Wed, Mar 02, 2022 at 12:44:45PM +0100, Jason A. Donenfeld wrote: > Hi Michael, > > On Wed, Mar 2, 2022 at 9:36 AM Michael S. Tsirkin <mst@redhat.com> wrote: > > Catastrophic cryptographic failure sounds bad :( > > So in another thread we discussed that there's a race with this > > approach, and we don't know how big it is. Question is how expensive > > it would be to fix it properly checking for fork after every use of > > key+nonce and before transmitting it. I did a quick microbenchmark > > and it did not seem too bad - care posting some numbers? > > I followed up in that thread, which is a larger one, so it might be > easiest to keep discussion there. My response to you here is the same > as it was over there. :) > > https://lore.kernel.org/lkml/CAHmME9pf-bjnZuweoLqoFEmPy1OK7ogEgGEAva1T8uVTufhCuw@mail.gmail.com/ > > Jason Okay. The reason to respond here was since this is the user of the interface. Maybe unite the patchsets? Thanks,
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(); }
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@dominikbrodowski.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.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(-)