From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi2-f16.google.com (mail-oi2-f16.google.com [74.125.231.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EB044854E8 for ; Wed, 16 Sep 2026 21:23:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.231.208 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789593850; cv=none; b=bAX8o+BTRC7sYhkAFrJcIprgsuMikGAHTb8+fi/SwgkuvonMCu0WN7QJCNCrasxVmEtX69ETMxJvF87hiaYXLaSyQlz2RFArIkqF6WHUriRyrxI0bd/97alxZlshcDz41phGAuanAan1zPq+WGIV44m4ngd4kxYRwyA1uxnl45s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789593850; c=relaxed/simple; bh=2UIZhQGNlp0yvgPj2bp76HRBxinSpLpWqq5nZWfgdJU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NmhSYVT/KVckrJL5HTxa1/F0RNSKJ05INcysSTGyIT2SVJ1m3xjp8q6c97erpc23LoFUOvbhQv8LbDQECKbomaWC9uFkq3KuyxkL2EvKJm9bkm2ySDa66B8dzsH61UJtbpNV97LBHYhP4w5zhnsRknICsGrwtuzqyWwKmhKvnag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=E8VT7AuZ; arc=none smtp.client-ip=74.125.231.208 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="E8VT7AuZ" Received: by mail-oi2-f16.google.com with SMTP id 46e09a7af769-7f4f0c89e35so112981a34.2 for ; Wed, 16 Sep 2026 14:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789593833; x=1790198633; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=XSIk8tJbuXToHcbml5dyAhA+YFmm4IR2Ghd4XhDQSyI=; b=E8VT7AuZmtBJ/hkPO9QDNVDywR5Qo7yLPcYymOuBSrOtscddz9rTh+tODZO7CS6LFA iODi/iWZecRrIoX8aX7F3t+sxGqAV1/2ZAy1/38AEENbjg+kz1A3oKFng8ULafqYw8Ba QgBf/shInGbGPoLSbXxQ3SLEPB5oo0IhKjQr3YaAQFJAxboomtF//wN3CCy0DkG5iJSV j/mugFRDXdYU+46JFVy5xQ8kVvSMwYS/8ex9DjWJpEMsG+p6oNzRbZtEq095Bg9Lc9Xo EQlaKECYEQoIqoglicLQZb5382NnSMVgGskQ0m40IMNBeybb8O95rUNJtEmDBAR3ykIz x77Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789593833; x=1790198633; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=XSIk8tJbuXToHcbml5dyAhA+YFmm4IR2Ghd4XhDQSyI=; b=rTL1gK1ePog7gm9gn4wo/nuagouDwPMNX7iuPXxhT4vtrrsQOZ/7XGBCNOygzRRZ8S QzcvvsimrOmMiDJOlC9AV1rTNOkrSdUd7sN5KAP3q4p0JPKLjRMFLGnD/DeEKtbsH7k9 Ni1+o+1wmK824ZI2QLBfgdGccR+eW/gzCLVaNVCDibU8auMCLBZ4PDcDn8XI39IqbZ4C 308NWLmvLTaWFEh7xM0G/3T97xhRnPUSrhnly/zuaYZ+322Y1HA/oKG6LwWrCdCiLY1s BS0x3WpvF2mRhkMSL+IOPEptXodYoOmvT429y938R5ImAOx1mtX1Kx9QZY3hJoFT1Rbh Z+RA== X-Forwarded-Encrypted: i=1; AKwUvBz2M98BytTR65JnkO0F9VuoZnWKzJON5nlYcQTkEYS+aWJ875qEQpC10RsujqTK4ofGSmoBJGiubZ6uCH8=@vger.kernel.org X-Gm-Message-State: AFuF++liq2umPADBYSDU9GdvJE3egVf+MGQPlG6ISZIdt7qh6j0pjx/Q epp+ORaohJHpHnBevGxnrAF4EHI4R0vSesZXUKidwGU9XDnkak9ukUzM X-Gm-Gg: AYBFou0wCB4m1oUnc06vh5dihTE4NCdSCmjZPh6gHXcV8vc8bGHdMW6g28wxZqTGVYN 8oHliLx+rZR99dmUr8J/ubGmhRU8rWRGWJr+nmpZeQxL1wvlYaWUqMWn+7RP9XcqN5hRIJefcNf 4diJuctU4QA3/7NWK1d/b/6Y59WqcDu7zAaT61Nj4hzt+aXR1iT8wOGptyB2x4YLcJHqS+tapmj 5lFpZTFuSkNimv+sLTEM4auZUHkhwgrXW/IN3pRZyGj2s6xVaYHidcnJX6uE2acHWvLWY0kExHk 6xAjOl+MTiBDI0m5bqQ+yNfaE7xnYyngfQcVNPgDx2081ctOMio/GGstO67GDEmAWbDJKw6j46V v0M9c/WQJdxmmpBZoQSs8yYdK3H6C2EMJ4ycEyq1i0DKgX/UFzriipuqnoJmZ2/38xWepPyovFN QlOrcT+0229v1pvgomtR9GZwmiG2/VRSWqLzybbnxiSpn2v2R4L42fWoI+wSFyrVmaeMFvMgKZE Z8wm/bgLgZUNPa/3e/Z X-Received: by 2002:a05:6830:6017:b0:7e6:ef1d:4aeb with SMTP id 46e09a7af769-80b2e0576bemr4670574a34.15.1789593833101; Wed, 16 Sep 2026 14:23:53 -0700 (PDT) Received: from devvm29614.prn0.facebook.com ([2a03:2880:ff:43::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-80c466a2dcesm1059784a34.11.2026.09.16.14.23.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2026 14:23:52 -0700 (PDT) Date: Wed, 16 Sep 2026 14:23:48 -0700 From: Bobby Eshleman To: Stefano Garzarella Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan , Stefan Hajnoczi , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Shuah Khan , Randy Dunlap , virtualization@lists.linux.dev, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, sargun@sargun.me, jlinbox@meta.com, Bobby Eshleman Subject: Re: [PATCH net-next 2/6] vsock: add IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS Message-ID: References: <20260902-vsock-guest-ns-v1-0-9995383e9a8b@meta.com> <20260902-vsock-guest-ns-v1-2-9995383e9a8b@meta.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Sep 16, 2026 at 02:57:43PM +0200, Stefano Garzarella wrote: > On Tue, Sep 15, 2026 at 11:50:10AM -0700, Bobby Eshleman wrote: > > On Tue, Sep 15, 2026 at 05:28:25PM +0200, Stefano Garzarella wrote: > > > On Wed, Sep 02, 2026 at 04:00:48PM -0700, Bobby Eshleman wrote: > > > > From: Bobby Eshleman > > > > > > > > Namespaces let a host isolate a VM's vsock traffic to a specific > > > > namespace, but in a guest vsock traffic cannot be isolated to a > > > > namespace. The vsock device is hardcoded to global mode and can't be > > > > moved into a local-mode namespace. > > > > > > > > Introduce ioctl IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS on /dev/vsock that > > > > > > We already discussed about netlink, but I'm not sure how much work can > > > take, here just another alternative, what about adding > > > /proc/sys/net/vsock/g2h_owner sysctl that can be read/write where: > > > 0 - no owner > > > 1 - owner > > > > > > 0 -> 1 transition, move the device in the new nets > > > 1 -> 0 transition, reset back to init_ns > > > > That seems reasonable, but if multi-device support ever lands, this > > might be harder to adapt cleanly? > > I see, but maybe we can have a dev0/ dev1/ subfolders in that case. > > > > > > > > > > gives userspace a way to move the device to the calling pid's namespace. > > > > The call requires CAP_NET_ADMIN in the root user namespace. A privileged > > > > user wishing to "unassign" the device can move it to the init_netns, > > > > which is hardcoded to global mode (so no unassign call is necessary). > > > > > > > > A getter to read the current assignment back was considered, returning > > > > either the namespace's net_cookie or its nsfs inode number, but neither > > > > seemed useful enough to bake into the uAPI now. It can be added later if > > > > a user turns up that needs it. > > > > > > > > Add a transport hook to indicate support for guest namespacing, so that > > > > transports may opt in/out. A transport that opts out keeps the > > > > reachability rules it had before this ioctl existed. > > > > > > > > Sockets are reset when the underlying device moves to a different > > > > namespace, so as to prevent reachability from the previous and now > > > > disallowed namespace. > > > > > > > > Following the approach of netdevs, the device returns to init_net when > > > > its namespace is removed. Care is taken to not break flows when the > > > > device is inside a global namespace that is being torn down and alive > > > > sockets are in a different global namespace. In this scenario, the > > > > device's netns getter pre-emptively falls back to the init_net (always > > > > global) so that these flows are not disrupted. If init_netns ever > > > > supports local-mode in the future, this logic will have to be changed. > > > > > > > > Suggested-by: Stefano Garzarella > > > > Link: https://lore.kernel.org/all/20200427142518.uwssa6dtasrp3bfc@steredhat/ > > > > Signed-off-by: Bobby Eshleman > > > > --- > > > > Documentation/admin-guide/sysctl/net.rst | 18 +++ > > > > include/net/af_vsock.h | 7 ++ > > > > include/uapi/linux/vm_sockets.h | 6 + > > > > net/vmw_vsock/af_vsock.c | 198 ++++++++++++++++++++++++++++++- > > > > 4 files changed, 228 insertions(+), 1 deletion(-) > > > > > > [...] > > > > > + > > > > +static void vsock_reset_unreachable_sock(struct sock *sk) > > > > +{ > > > > + if (vsock_g2h_net_reachable(sock_net(sk))) > > > > + return; > > > > + > > > > + sk->sk_state = TCP_CLOSE; > > > > + sk->sk_err = ECONNRESET; > > > > + sk_error_report(sk); > > > > > > Should we send the reset to the other peer too? > > > > > > Or avoid to set TCP_CLOSE, so the user will see the error and close it? > > > > Sending the reset sounds good. At least the peer won't be waiting around > > forever. Will work that into v2. > > If it's too much of work, we can skip it, it's not a strong opinion on my > side. It was more a question of what we should do ;-) > > > > > > > > > > +} > > > > + > > > > +/* Move the g2h device to @net. Returns -ENODEV if no g2h transport is loaded > > > > + * and -EOPNOTSUPP if the loaded one cannot be moved. > > > > + */ > > > > +static int vsock_g2h_net_assign(struct net *net) > > > > +{ > > > > + int ret = 0; > > > > + > > > > + mutex_lock(&vsock_register_mutex); > > > > + if (!transport_g2h) { > > > > + ret = -ENODEV; > > > > + } else if (!vsock_g2h_netns_assignable()) { > > > > + ret = -EOPNOTSUPP; > > > > + } else { > > > > + /* See vsock_maybe_set_connected() comment about synchronizing > > > > + * with connecting sockets. > > > > + */ > > > > + rcu_assign_pointer(vsock_g2h_net, net); > > > > + vsock_for_each_connected_socket(transport_g2h, > > > > + vsock_reset_unreachable_sock); > > > > + } > > > > + mutex_unlock(&vsock_register_mutex); > > > > + > > > > + return ret; > > > > +} > > > > + > > > > +/* Move the g2h device back to init_net if it lives in @net, which is about to > > > > + * be destroyed. > > > > + */ > > > > +static void vsock_g2h_net_reset(struct net *net) > > > > +{ > > > > + bool reset = false; > > > > + > > > > + /* Avoid taking the mutex if the namespaces don't match. */ > > > > + if (likely(rcu_access_pointer(vsock_g2h_net) != net)) > > > > + return; > > > > + > > > > + mutex_lock(&vsock_register_mutex); > > > > + if (rcu_access_pointer(vsock_g2h_net) == net) { > > > > + rcu_assign_pointer(vsock_g2h_net, &init_net); > > > > + reset = true; > > > > + } > > > > + mutex_unlock(&vsock_register_mutex); > > > > + > > > > + if (reset) > > > > + synchronize_rcu(); > > > > +} > > > > + > > > > static struct sock *vsock_dequeue_accept(struct sock *listener) > > > > { > > > > struct vsock_sock *vlistener; > > > > @@ -2745,6 +2920,15 @@ static long vsock_dev_do_ioctl(struct file *filp, > > > > retval = -EFAULT; > > > > break; > > > > > > > > + case IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS: > > > > + if (!capable(CAP_NET_ADMIN)) { > > > > + retval = -EPERM; > > > > + break; > > > > + } > > > > + > > > > + retval = vsock_g2h_net_assign(current->nsproxy->net_ns); > > > > + break; > > > > + > > > > default: > > > > retval = -ENOIOCTLCMD; > > > > } > > > > @@ -2978,6 +3162,7 @@ static __net_init int vsock_sysctl_init_net(struct net *net) > > > > > > > > static __net_exit void vsock_sysctl_exit_net(struct net *net) > > > > { > > > > + vsock_g2h_net_reset(net); > > > > > > Why calling this in the sysctl_exit ? > > > > Should we add another pernet_operations? I agree the name of > > vsock_sysctl_ops does not really fit as a general "do all per-net > > operations here" location. > > Aaaaa, it's not really related to sysctl. > > Maybe we can rename it or add another pernet_operations. > > > > > > > > > > vsock_sysctl_unregister(net); > > > > } > > > > > > > > @@ -3104,13 +3289,21 @@ EXPORT_SYMBOL_GPL(vsock_core_register); > > > > > > > > void vsock_core_unregister(const struct vsock_transport *t) > > > > { > > > > + bool g2h_net_reset = false; > > > > + > > > > mutex_lock(&vsock_register_mutex); > > > > > > > > if (transport_h2g == t) > > > > transport_h2g = NULL; > > > > > > > > - if (transport_g2h == t) > > > > + if (transport_g2h == t) { > > > > transport_g2h = NULL; > > > > + /* The device is gone, so is its namespace assignment. */ > > > > + if (rcu_access_pointer(vsock_g2h_net) != &init_net) { > > > > + rcu_assign_pointer(vsock_g2h_net, &init_net); > > > > + g2h_net_reset = true; > > > > + } > > > > + } > > > > > > > > if (transport_dgram == t) > > > > transport_dgram = NULL; > > > > @@ -3119,6 +3312,9 @@ void vsock_core_unregister(const struct vsock_transport *t) > > > > transport_local = NULL; > > > > > > > > mutex_unlock(&vsock_register_mutex); > > > > + > > > > + if (g2h_net_reset) > > > > + synchronize_rcu(); > > > > > > Why we need this? (I'd add also a comment with the reason) > > > > We might actually be able to drop it... I do think we need to keep it in > > vsock_g2h_net_reset() because it makes sure that vsock_g2h_net_get() > > doesn't dereference a destroyed net. > > > > vsock_core_unregister() isn't on the teardown path, so even if we > > re-assign to init_net the previous net is still alive. > > Agree. > > > > > > > One thing I realized when answering your uAPI questions and looking at > > the code is that IOCTL_VM_SOCKETS_GET_LOCAL_CID is not namespace aware, > > but I think it probably should be? I remember for host ns we strived for > > truly strong isolation. > > Can you elabore a bit more? > I'm wondering if IOCTL_VM_SOCKETS_GET_LOCAL_CID should not reveal the CID of the g2h device if the device has been moved to an inaccessible namespace? In this case, fallback to the results of h2g/local and through to returning VMADDR_CID_ANY if neither of those transports are loaded. I also considered whether or not /dev/vsock should even be visible from within an inaccessible namespace in order to not leak even the mere presence of the vsock device, but it seems to me that /dev/vsock's presence doesn't leak anything besides the presence of the vsock module. Best, Bobby