foreign
[Music]
hello everyone this is I believe the
last Talk of the day
um and we have with us uh David Gibson
who has had a 20 plus year career
working almost entirely on open source
projects uh a lot of this work is in and
around the Linux kernel and David will
be describing an older networking
technology uh and how it's being
modernized for use today so please give
David a warm welcome
[Applause]
hello uh I'll start by acknowledging the
traditional custodians of this land the
wooden Jerry where were wrong people and
I extend my respects to their Elders
past present and emerging
all right
hang up
so
just as we start quick show of hands
here who has used dial-up internet
who has used a BBS system
all right who has used uh slurp to get
their dial up internet
all right a few people
and who recognizes the similarly dated
quote there
or reference rather
anyway we're going to talk about ancient
history specifically the 1990s
so this is the world of dial up
well dial up things dial up internet so
modems and dial up from home are an
established technology at this point
internet access is common at
universities at this point and it's
there in some organizations but not a
lot
commercial isps are still kind of
uncommon and kind of expensive
uh however and this will become
important in a moment there are quite a
few students and staff I think this is
more in the US than here uh have access
to dial up shell accounts but not dial
up internet accounts
so what does what does dial up look up
look like if it's not internet
um so a few of you might be familiar
with bbs's these are all systems a text
interface you dial into this system and
you can do a bunch of stuff you have
these menus you could exchange users
exchange messages upload and download
files play various games uh bits and
pieces they vary in exactly what they
could do but these were around and
popular for a little while
so what does that look like from a
systems point of view you've got your uh
home computer here uh probably not a
laptop in 1995 but we'll just go with
that
you've got your terminal program there
and it connects through to the some
software running on the BBS system
um and you say surely it's more
complicated than that and well yes
there's modems and stuff
but that's not what this talk is about
for our purposes your talk your software
talks to their software in user space on
both ends and uh that's how bulletin
board system works
so meanwhile at the University which
does have internet what does that look
like they've got an internet host it's
got some kind of real uh network
connection to the outward world even in
the 90s it was probably ethernet but
there were a few other options which
were more common then than they are now
and you could run whatever Network
applications on there
um you know a gopher server or uh what
else was around then email of course
uh FTP would have been around then I see
yeah various things and they they
connect out to the world uh through
primarily TCP and UDP sockets and
um that all goes over the the L2
um
Ethernet or whatever Network
and again there's more complexity here
in what that connection actually means
there's various levels of router and so
forth but that's also not what this talk
is about
so if you did manage to get dial up into
that at this time uh how did that happen
so you have your home computer again you
have some kind of access point maybe you
know someone at the University maybe you
uh had access to you managed to have
access to an ISP or something
and every scene we can get a dial-up
serial link from your software to their
software so we want to change this into
a network link
and the way that was generally done at
the time was using a program called SL
attach which kind of wired that serial
link into the kernel and said please
treat it as a network link using slip
which is the protocol
serial line IP so internet over a Serial
line
now the important thing about this is it
needs you to have root or at least some
kind of privilege on both ends s will
attach needs to talk to the colonel
and
um
and tell it to to plumb the serial link
into the kernels networking and so you
need root on both ends which is why you
can't just do this on on any old system
so like I said isps are a bit uncommon
at this stage but some people had shell
accounts
so they don't have root on the
University server but they can run
whatever they
more or less whatever they want in user
space on that machine so that's the the
red is the things you control the black
is the things you don't
your home computer you can connect up to
there you can run you can run Elm to do
your email you can run a news client
um things and they can they can do
Network stuff
what you can't do is run Mosaic on your
home PC and and download interlaced
pictures of cats for example and I hear
that was all the rage at the time
so
so the situation here is you've got root
and you've got control over the
networking uh over here on your home
system
but you don't have any connectivity
and your network connectivity over here
you have network connectivity but you
don't have root
so is there some way we can connect the
two together
and
um there we use it was a program called
slurp exactly how that spelled and
capitalized varies quite a bit
um
but on your end this looks just like a
slip link
um you you wire this slip link into the
kernel but on the other hand and that
link terminates in user space it doesn't
talk to the or it doesn't talk in a
network Administration capacity to the
uh to the server end
uh instead it it makes magically makes
this happen by talking regular user
space TCP and UDP sockets so how does it
do that
well we can uh and uh
the the effect of this is uh once once
you've got this set up it looks like
you've got a a network connection out to
the outside world and exactly how you
wire that in kind of no longer matters
how does that work we'll zoom in onto
this University server here we've got
the internet coming in through some kind
of network interface and its driver
and inside the kernel over there there's
a tcpip stack which effectively splits
that thing up into the various
UDP and TCP
theoretically a few other things mostly
TCP and UDP connections into user space
so what slurp does is it takes another
TCP stack specifically the one from 4.4
BSD
and turns it on its head and takes all
those sockets and puts them back
together into an L2 stream which it
sends over a slip connection back to
your end
if you think this sounds like a gigantic
hack
it is
but it was a very useful one at the time
Okay so
Let's uh dial the clock forward a bit
isps became common and cheap triple P
replace slip broad pan replace dial up
no room for this hack anymore right
okay well virtual machines became a
thing uh
I guess in the 2010s ish
so this might look a bit odd to you
because you might be used to thinking of
the virtual machine as running on top of
the host machine but what I'm looking
here at the is the network point of view
so from that point of view the virtual
machine is essentially an independent
system from the host so you have the
host machine here
you have qmu which creates the uh
virtual machine there are other things
but qme is what we'll talk about here
and so that creates this uh virtual
machine
and you kind of automatically have a
link from the virtual machine through to
qmu because qmu creates it and emulates
that Network so you've got this emulated
Ethernet there just by the nature of How
It's implemented
so what you can what can you do with
that well one thing you can do is if
you've got two virtual machines
you've got two qamus two things wired up
there
you can make a socket between those qmus
and you can
connect the
um
connect those all back to back and give
you what looks like a a network
connection directly between those two
virtual machines
um that's usually that's what the
definite socket or Dash net stream
options of qmu
um they're basically equivalent streams
just a bit newer for reasons
but connecting to another VM isn't all
that exciting you really want to connect
to the outside world
so how would you do that
was the qmu.net tap option and what that
does is
uh it takes that emulated thing and it
uses the tap device or the ton device
there's a few other variants of it
and wires those up to give you what
looks like a network connection from the
virtual machine to the host machine
but you'll notice again here that again
you need root or at least some kind of
elevated privilege on that host machine
in order to wire up the tap device into
the host's networking stack
if you're deploying a you know
production system of VMS that's probably
not a problem you can wire everything up
you set up your VMS to have the right
sort of accessibility this is typically
what you do
if however you're just developing you're
just testing you don't really want to be
root for this so
now you've got a host machine where you
don't have privilege
and you want to give Network to your VM
and this should look familiar at this
point you've got one place where you
have
root access in fact you completely
control the virtual Hardware
but no connectivity
and you've got another place where you
have connectivity but you don't have
root access you don't have Network
administrative access
so were you slurp uh qmusic.net user is
slurp it's actually based on a newer
version of that very same code base in a
form called lib slurp and it basically
works exactly the same way it takes the
emulated ethernet of qmu wires it up to
a bunch of sockets that qmu sends out to
the outside world and it looks like you
have network connections hooray
VMS are a bit passe these days these
days it's all about containers so how
does networking work there
well in this case
um podman could be Docker whatever
uh uh just sets up a virtual ethernet
device between your container and the
host the data doesn't actually go
through podman in this case it just
configures it
um but this is typically how it does it
it creates a v device uh could be back
VLAN there's a few options
um wires them straight up again
needs root on the host
uh or at least some kind of raise
privilege some kind of privileged helper
program something like that
typical way it's done
more recently
uh podman has added an option for what
they call rootless networking so how can
you give a container network access if
you don't have root on host
and it slip
a particular it's a variant called slip
phonetiness that is slurp hooked up to
talk to a network namespace like having
a container rather than a VM or a
virtual Ethernet or or anything else
like that
so
so this supposedly ancient hack is is
still seeing some life
um little diversion uh containers and
kubernetes together
um people may may not have heard of of
cube vert it's a it's an extension to
kubernetes essentially designed to run
VM workloads on a kubernetes cluster
um this is quite useful and you've got
existing VM workloads and you want to
move them into Cloud environments
and specifically how it does that is it
essentially runs qmu inside a kubernetes
pod to fire up the VMS but the important
thing is it's not just enough to run
these VMS they need to talk to the rest
of the cluster because you could have
apps that are split across some
containerized pods some VM pods
whatever so all these components need to
talk to each other the VM networking
needs to integrate with the kubernetes
networking
right so what's that's gonna what is
that going to look like
you've got a kubernetes pod
um
it talks to the internet but more
immediately it talks to the rest of the
cluster that's kind of significant in
this case inside the Pod you've got qmu
it creates a virtual machine again
this might look a bit odd the virtual
machine not being inside the pot as it
were but this is a networking View and
from that point of view it's a it's a
different network space from the uh it's
a different host in the networking sense
from the from the pod
and so you might say well Cuba creates
that pod so it's got administrative
access over it right so it can just do
the typical thing wires up the Mac VLAN
um gives you a virtual ethernet
hunky dory
he can uh it does that right now it
works for some things
but not for other things there's
actually two modes it can use
um there's bridge mode uh I there's a
lot of details I could go into here
that's kind of a focus of this
um so if this doesn't make a lot of
sense to you it doesn't really matter
we'll come back to other things in a
minute
you've got bridge mode in bridge mode
the VM essentially takes over the IP
address of the Pod takes over the
network interface of the pod
uh that works great when it works uh
pods can have multiple containers in
them if you have other containers often
called sidecar containers this will
completely break them because they don't
have an IP anymore so
that's good until it's not there's also
masquerading mode in that way
you it uses the kernel Nat masquerading
to connect the VMS interface to the
external pod interface
uh there's a couple of problems here one
is that the guest doesn't see the the
doesn't see the same IP as the Pod
anymore
and kubernetes are apps tend to assume
that the Pod IP is something that
everybody agrees on that that all the
components of the ad know about and
don't have to translate in any way
it also breaks service meshes this is
something I don't know a lot about
um
it's related to the fact that in service
meshes uh at a sidecar
a sidecar routes the traffic and expects
it to come from the pods user space and
in this case because of the way it's
routed through the kernel Nat it's not
coming from user space and everything
falls down horribly
so we need something different in order
to get Cube there this is the original
motivating case for past and pasta which
I'm going to talk about in a minute
we need a different approach um in
addition to those kind of fundamental
problems actually although you can get
privilege in that kubernetes pod it's
kind of a pain
kubernetes tends to not make that very
easy and Cuba has to use a bunch of
tricks in order to get the privilege it
needs to set that up
so we want VM traffic to appear if it's
coming from the Pod user space we wanted
to connect the L2 to The L4 interface we
already have
slope again right
well no not quite
there's a few problems with slurp the
big one is that slurp always gnats slurp
obviously being a user space program has
no power to allocate new IP addresses
out of anywhere or to control or routing
on the host
uh so the way it does that is it gives
the guest
an address on a on a private Network
usually a 10 dot Network
and inside the slurp codes this is not
using the kernel Nat but inside slurps
internal TCP stack it includes address
translation to translate that into
addresses in the outside world
like I said kubernetes really isn't like
that uh it pod IPS are expected to be
Global across the cluster
security is not great either it's got a
pretty poor track record particularly
for resource leaks memory leaks and the
like
complete tcpip stack is actually pretty
complicated so there's a fairly large
attack surface there and slope has a
bunch of extra features for
this that and the other increases it
still further it's an old code base
fairly difficult to maintain
and in the case of lube slurp as it's
used in qmu that is literally a library
it shares address space with qmu so
if you compromise some of qmu you can
attack lib slurp and the other way
around so we've got no isolation between
the components there
performance is also pretty bad
um because alert was never really built
for performance it turns out that even
in the mid 90s it's pretty easy to keep
up with a with a modem with a dial-up
modem
um since then computers have changed a
bit networks have changed a lot and you
really need different techniques to have
uh decent uh performance
in particular slurp has no support for
TCP window scaling
um which means you could have most 64k
of data kind of in flight without an app
which is plenty on a 56k modem but not
on a multi-gigabit
virtual Network link on your container
uh it also has uh not very much IPv6
support it's kind of been hacked in but
there's a bunch of things it doesn't
support
all right so where are we now we want
something that's like slurp but not
slope
and here is past
so past is a modern written from scratch
L2 to L4 Bridge so
same concept of slurp connecting a
virtual Ethernet or a virtual L2 network
connection to regular old user
unprivileged TCP sockets
uh stands for plug a simple socket
transport
um I believe it's past is is a word
meaning kind of adequate in German kind
of slang
um it was originally written by Stefano
brivio starting late in 2020
I started working on it uh just under a
year ago
and so I'm the second main contributor
to it it's about 9 500 lines of C
excluding comments
and we and we got a bunch of particular
depend design goals uh for this to
address those problems we saw with slurp
so we want to avoid dependencies so that
we don't have a big supply chain of
dependencies to to check
we want to avoid Nat we can't completely
but we mostly can and we'll see how in a
moment
uh we want to avoid dynamic memory
allocation entirely if you're not
allocating memory dynamically it's very
hard to leak it
we want it to perform reasonably we want
it to be security conscious and we want
it to support IPv6
just as well as ipv4
so how does this work we have passed and
we have qmu running on the same host I
ran out of space a bit there so that qmu
is running on the host it's just a bit
offset
we connect them with a Unix domain
socket and what we do here is we use
exactly the same protocol that we talked
about briefly earlier where qm you can
talk to another qmu back to back and do
networking over that so we talk that
same qmu socket protocol
and using that we connect our virtual
machine up to past it does the
slurp-like bridging thing and we have a
network connection so this is again
using the Dash net stream option in qmu
it does actually have to be that net
stream these days this is one of those
slight differences Dash net socket
could only do TCP sockets and we prefer
to do this over a ux demand socket Minor
Details
like internally
um so over here on the left we have this
virtual L2 so this is coming in over the
socket from qmu
uh we essentially split that up based on
the protocol uh TCP and UDP are simple
enough we just translate those into
socket calls on the host kernel
uh we can't deal uh entirely with icmp
and icmpv6 we can handle some things
though in particular uh modern kernels
we have what are called ping sockets
which does allow you to do pings as
regular unprivileged sockets so we can
do that
and for us in pov6 there's a subset
called NDP network discovery protocol so
that's how the guest can find out an
address find out what its route is
supposed to be we internally answer
queries from that so that the guest does
what we expect it to
likewise we answered DHCP and DHCP V6
and op requests all internally
and to do that we use netlink to talk to
the host kernel to get the information
we need to supply there
so how do we avoid that
uh the guest seems the same IP address
as the host even for IPv6 yes that's
weird
uh and it gets that IP address from uh
of it can get it from DHCP or DHCP V6 or
from NDP any of those methods will let
the guest discover the address it's
supposed to have which it'll be told the
same address as the host
you can configure it but by default it
takes it from the host interface with a
default route default route so it'll
usually take the the primary in a sense
network interface of the host
this works great for the guests
connecting out to the outside world
but obviously if you've got the same
address as the host there's no way to
actually address the host itself
we have a special case Nat for that so
we take a special address that the guest
can use to address the host
actually specifically it's mapped to the
to 1270 to the loopback address on the
host so actually talk to the guest as if
we're to talk to the host as if we were
local rather than talk to the host as if
we were from somewhere else which is
usually what we want
this is a bit limited I'll come back to
this in a minute there's also another
special case for handling DNS queries
um
but I mean this is a different trade-off
from that's it's in some ways less
elegant than using that
but it works much nicer in a thing like
kubernetes where Nat really confuses
high levels high level software
security
we have a bunch of bunch of approaches
um using some more modern socket
interfaces
uh we don't need a complete TCP steak
machine we can get away with a kind of
cut down one that simplifies things
smaller Tax Service like I said we avoid
Dynamic allocation completely and that's
actually enforced with setcomp so even
if something gets in and tries to
allocate memory it'll get a success and
just die
we use a bunch of uh static Checkers the
routine checks have CPP checking Clank
tidy we run coverity scan from time to
time
no external dependencies so what you see
is what you get it does use the standard
C library but nothing more than that
moreover we do a bunch of sort of second
layer security things we isolate
ourselves using Linux namespaces so
and we actually use pivot root so once
the thing has configured itself you
cannot touch the host file system from
inside the past process context
um and we also isolate a bunch of other
namespaces so
most of the host systems you can't uh
after at least after configuration you
can no longer touch on the host uh like
I said we use set comp we filter down to
currently only 26 assist calls on x8664
the exact set we need depends varies on
depending on the architecture for
complicated reasons
uh we drop capabilities uh in both where
we started and in that isolated
namespace when you create a namespace
you get capabilities in there but we
drop them again
and we ship with app armor and SE Linux
profiles included so we've sort of got
multiple layers of isolation here to try
and keep this secure
uh performance
um you do a bunch of things in in TCP we
actually advertise a very large MTU to
the guest a 64k MTU so much bigger than
a normal ethernet would be like um 1.5 k
and we coalesce our TCP segments as they
come in
um
which means that even if we've got a lot
of packets coming in from the outside
we can do relatively few packets into
the guest which reduces the overhead
reduces number of ciscals
for UDP we use these uh send M message
and receive M message there's two M's
there which matters uh which are single
sys calls that can send or receive a
whole batch of packets a bunch of
datagrams with one call
um
again less ciscals uh we use we've got a
ovx2 accelerated checksum on x86
um
in theory could be done on other
platforms just hasn't been yet
and we use some buffer pools where we
pre-partially pre-generate the headers
the main benefit of that is data
locality not so much just saving the
writing that's fairly cheap but it does
improve uh delically
I'm not going to give you numbers today
they're a bit in flux
um it is much faster than slurp
it is pretty comparable to a tap just a
plain single threaded tap connection
it is significantly slower than
multi-cue tap at least once you get to
sort of four or eight cues
uh we probably won't ever fully compete
with that but we hope to be competitive
enough to be useful in in real world uh
real world situations
like I said we've got full IPv6 support
we support NDP internally and DHCP V6
there's basically it's pretty much
completely symmetric between V4 and V6
support
and we have uh slope had this as well
but it's a bit more flexible in past you
can
control which ports on the host will
forward into the guest and you can
select all the ports with something Cube
that wants to do at just particular
ranges just particular ports
faster
this is a variant on the same thing so
this is the equivalent of slurp for net
and S this is basically the same thing
but instead of a VM you have a namespace
or a container
as you guessed
this does require privilege in that
namespace but not on the host
uh it's implemented in the same binary
as past
it's also got an accelerated path for
local to local that uses splice for TCP
which goes very very fast
uh you can afford ports outwards as well
which
the semantics are a little bit weird but
um it can be useful
all right so what uh pasta looks like
there is um you've got a network name
space that could be a container it could
be one you've set up by some other means
um and that just uh we use a tap device
to connect that through now you might
ask why is the tap device okay here but
it wasn't okay
uh in the other cases and the the answer
is that
in this case we only need the privilege
in the container and not on the host end
which is what makes this work whereas
tap in other situations would not work
uh we have packages for Fedora uh Centos
uh Debian Ubuntu unofficial ones for a
couple of other things
uh we've got some more on the way
in theory it should be just about
neutral to architecture it's tested on
on
non-x86 a little bit but not a lot
uh we support libsy and we're working on
uh muscle support right now
it is Linux only uh it uses a bunch of
Linux specific kernel features there are
alternatives uh in on some other os's
but not ones you can just drop in
um they're ones where we'd need a
specific port to other operating systems
and we're working uh or something we've
been working a lot on is integration
with other things so just recently uh
support's gone into libvert it actually
went in liver 900 but there are some
bugs if you've got SC Linux enabled
which should now should be fixed in 920
so that's you've got a network
configuration option in
um
in liver that says use past instead of
whatever other options you had for
networking
uh we we've got this supported in podman
as an alternative to slip for net NS for
us networking
and uh
uh keywords uh it is in there we've hit
some complications which we are
gradually working on
um it's not as smooth as we would like
at the moment but we're hoping it'll get
there
all right we're actually from here
uh probably the highest priority is we
do have some uh
less than optimal things that we're
trying to work on
um like I said the net is a bit
inflexible and it's got some weird edge
cases uh we want to improve that make it
more consistent uh more flexible
uh and more robust against different
configurations
um so that's something
we're not working on right at this
instant but it's kind of high on the
queue for us to get at
uh one problem and this is one of the
complications with Cube vert is it can
use a lot of Kernel memory if you're
forwarding a lot of ports so they were
forwarding essentially all the ports
from the Pod into the VM
so if you've got TCP UDP ipv4 and IPv6
that's about 200 000 listening sockets
that takes up quite a lot of Kernel
memory we've got a couple of things
there where we can reduce it we've
reduced it a little bit
there's only so much we can do we do
actually have some ideas for some kernel
extensions which would bring let us
bring this way down not sure where
that'll go but we've got a few ideas
there
testing in CI is uh
not as good as we'd like it is a bit too
fragile and dependent on the host's
network setup
so we hope to improve that improve
coverage there
uh big thing in terms of performance
we'd like to add support for V host
users so instead of using that qmu
socket protocol we interact with qmu via
a v host user
that should go a lot faster at least if
we can multi-thread it which is perhaps
not trivial but
um we're looking at it
we'd like to do fuzz testing uh
theoretically easy practically kind of a
pain to get all the bits lined up to
work
and we'd like it to be more portable
particularly BSD and Darwin it would be
nice to have
um
ports there we think there are the
network features but we kind of aren't
experts in that area
modernist writing something new in C
that's security conscious these days is
perhaps an interesting choice
um
we have certainly thought about using
rust in in places to improve that kind
of memory safety it's not trivial
because we have a bunch of low-level
interactions so we'd certainly need
uh unsafe and a few things to deal with
possible use cases we might add
um it could replace stash net you the
current dashnet user in qmu uh
theoretically straightforward nobody's
had time to work on it yet
may have some uses in Carter containers
um
this is an interesting one clatt is a is
a
internet draft for running ipv4 only
applications in an IPv6 only network
with a sort of
it's kind of like Nats but ipv4 to IPv6
in a sense and past could possibly be
extended to do that and we're interested
to hear of new use cases that other
people might have
we would welcome contributions uh
there's two main people we've got a few
other people uh it's quite active at
this time and
we're sort of really on the cusp of
going from an experimental thing to
something that can really be used so
um if people are interested in
uh
there are places you can contribute
um there's a link there to another
presentation that Stefano did at I think
last year's KVM forum which has some
slightly different information
uh all right credits there
uh so that's basically the end
um
if people want to ask questions I
suggest you prepare that and meanwhile I
will give a brief demo here
I think we have like eight Tish minutes
left
I think about David
um
it's a question around how you found the
L4 decapsulation maps to the modern
socket API like could either be a
nightmare or brilliant like ah
I'm not totally clear a clear which
aspect of that you're meaning
um is it is it a fairly linear process
to go from your L4 decapsulation into
the soccer cores available or is there a
lot of code that has to manage like your
sequence numbering your uh TSB options
in between it's not trivial
um it's not
super complicated either
um
so
so here we have it uh we can build it
oops
so
it doesn't take terribly long to compile
because that's less than 10 000 lines of
code
and the easiest way to invoke it
is uh with pasta the
um
namespace version if you run it with no
arguments it will create a new namespace
for you so actually I'll show you here
so I'm not root as you can see
uh on this system we have a couple of
network interfaces we have the main one
being the the wireless here which is the
one that's connected at the moment
we can uh
just run past it without things and now
we appear to be root
um we're not really root we're root
within this namespace
so if we actually try to for example uh
you know create a file
that will fail because we're not rooting
the
init namespace
but we are a root within this user and
network namespace where it actually
copies that interface name which is why
it looks like the same device here but
you see we don't see the other
interfaces so this is actually the
pastor created uh interface
and we can
uh
run a DHCP on that
and again that permission denied is just
because we're not rooting the main
namespace I haven't told this to put its
uh its log file somewhere else
and that will have configured the
interface I don't does the LCA Network
have ifub6 doesn't look like it so IPv6
is not going to work here and now we can
do something like
try to connect to the outside world
and
yes of course Tracer out is going to be
a bit weird because everything's kind of
proxied through our
user space intermediary
but we can do something like
um
uh
just uh get a web page and we have
something there so not a very extensive
demo but there is any other questions
or things you'd like me to try on this
demo
I'd be interested in hearing a little
bit about it can you yeah I should know
that hello I'd be interested in hearing
a little bit about
um
what
what would be involved in using rust
instead of C so
you said you'd have to use unsafe a lot
does that sort of negate the benefits of
using a language like rust in place of C
or is it not necessarily
um it does it depends how much you have
to use it you do have to be
it at least marks the bit you need to be
careful of
um
in order to do it well you do need to
think pretty carefully about what your
abstractions are and what the invariants
are you need to maintain in the unsafe
code
which can be
tricky it doesn't completely negate
the the benefits but it does mean
they're much more conditional and
um
they're harder to harder to reach
if that makes sense
yeah
one one option we we would have that we
could look at if we were doing that
would be to put all the sort of
configuration and startup command line
parsing that stuff into rust and then
basically have a c module that does the
runs the engine uh once that's all set
up
um
that makes a lot of theoretical sense
um again it's a bit of a pain because we
have to
we have to pack all the information we
need for that engine which is not huge
but it's not nothing
and we have to package that in a way
that both the C code and the rust code
can access which can be done but it's
just another layer of complication so
there's a bunch of options but it's
it's not kind of a no-brainer to do yeah
it looks like this question up the back
there
I was wondering the no dynamic memory
allocation I can see that it'd make a
big difference to the security how hard
was it sort of dealing with that or it's
fairly stateless so it doesn't uh it's
not that bad um that honestly when I
came on that was already essentially
done
uh the main thing it requires is a
interesting hack in TCP
the perhaps the biggest barrier there is
the most obvious way to implement
something like this is for every
connection you have a buffer that
stashes information where it's in
between the two sides and if you had to
allocate that every time you made a new
connection
that would be a problem
um now you could do that and we we do do
you use a bunch of static arrays so we
just have a connection table not
containing a buffer in fact but we do
have a big connection table with
pre-allocated
uh do that would be even huger than it
is if we had buffers in there the way
we're able to get away with it without
buffers is a bit of a hack using the
message Peak option what we actually do
is when we take data from the TCP socket
we initially just Peak it so it stays in
the kernel buffers
and we only discard it from the kernel
buffers when it gets acknowledged from
the other side so we're kind of able to
abuse the kernel socket buffers there to
avoid allocating our own buffers which
is an interesting trick
together
I think somebody there
had a question
so I noticed you said you're reporting
it
I know you said you were putting it to
Amazon is is dynamic memory allocation
issue there because obviously libsy
might decide to do allocations you're
not expecting so sorry Port 2
um for Alpine
uh and your nusl oh right
um sorry what's the so so let's see
might decide to do dynamic memory
allocation that you're not expecting is
that that that's probably less of a
problem with with muzzle than it was
with glibc gillibcy allocates in a bunch
of places we do have a bunch of hacks
there to convince glibcy to not call
Jill Ipsy we actually avoid several
gelib C functions which would be obvious
choices like the um we basically have
our own uh stuff to talk the syslog
socket rather than using the normal open
log and syslog functions because those
allocate in glibc there are a bunch of
hacks like that to avoid that it's
probably easier and muzzle than is in
glibsy
um
all right time is up for questions thank
you very much
[Applause]