[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YyjVQxmIujBMzME3@mattapan.m5p.com>
Date: Mon, 19 Sep 2022 13:46:59 -0700
From: Elliott Mitchell <ehem+xen@....com>
To: Demi Marie Obenour <demi@...isiblethingslab.com>
Cc: Xen developer discussion <xen-devel@...ts.xenproject.org>,
netdev@...r.kernel.org
Subject: Re: Layer 3 (point-to-point) netfront and netback drivers
On Sun, Sep 18, 2022 at 08:41:25AM -0400, Demi Marie Obenour wrote:
> How difficult would it be to provide layer 3 (point-to-point) versions
> of the existing netfront and netback drivers? Ideally, these would
> share almost all of the code with the existing drivers, with the only
> difference being how they are registered with the kernel. Advantages
> compared to the existing drivers include less attack surface (since the
> peer is no longer network-adjacent), slightly better performance, and no
> need for ARP or NDP traffic.
I've actually been wondering about a similar idea. How about breaking
the entire network stack off and placing /that/ in a separate VM?
One use for this is a VM could be constrained to *exclusively* have
network access via Tor. This would allow a better hidden service as it
would have no network topology knowledge.
The other use is network cards which are increasingly able to handle more
of the network stack. The Linux network team have been resistant to
allowing more offloading, so perhaps it is time to break *everything*
off.
I'm unsure the benefits would justify the effort, but I keep thinking of
this as the solution to some interesting issues. Filtering becomes more
interesting, but BPF could work across VMs.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sigmsg@....com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Powered by blists - more mailing lists