
Smoltcp: A small TCP/IP stack in Rust - adamnemecek
https://github.com/m-labs/smoltcp
======
littlestymaar
This is a really good example of the kind of safety benefit you get when using
Rust: this is a fairly low-level piece of software (not a kernel, but I'd say
it's lower-level than at least 80% of what's usually written) and yet, only 76
lines of codes are located inside unsafe blocks for the whole code-base. To be
safe from memory vulnerabilities, all you need is audit theses 76 lines. It
can still be a tough job, and bugs may slip past the review, but it's a huge
improvement over having to audit thousands of lines.

~~~
nsajko
> safety benefit

Has "safety" become a buzzword? What we really strive for is correctness.
Hypothetically, Rust could still be detrimental to software correctness
compared to a more usual language, if some of its traits as a language (eg.,
complexity) encourage bugs. Sometimes it seems like Rust afficionados think
that buffer overflows etc. are the main kind of bugs.

And if you need absolute correctness (when human life depends on the software)
you would probably use Ada and Spark or something else that enables you to
actually prove correctness.

~~~
llogiq
> Sometimes it seems like Rust afficionados think that buffer overflows etc.
> are the main kind of bugs.

Have you looked at the CVE stats of the last decade recently? Memory errors
make up around 3/4 of that. Even if Rust would make the last quartile harder
(which in my experience it doesn't), it could still be worth it for many
applications where you cannot afford full verification, but want to avoid your
users being pwned.

~~~
nsajko
I would bet 99% of that 3/4 (or at least the part written in C) could have
been caught with testing, fuzzing, and sanitizers we have today.

~~~
littlestymaar
Too bad neither Microsoft, Google or Apple ever heard about those tools…

~~~
pjmlp
Or even Linux, with its strict patch process, still managed to have 68% of
2018's kernel CVEs, related to memory corruption issues due to C's use.

------
haberman
I have a distant memory of Alan Cox saying something back in the day along the
lines of "there are so many things left undocumented in the TCP/IP RFCs that
if you just implement it straight from the spec your stack won't work at all."

But I can't find any reference to this now. Does anyone else remember this?

Is this true? Can you interoperate with the Internet by just implementing the
spec?

~~~
jsnell
No, it's not true. You can implement something that can load a webpage from
99.9% of the world's web servers from a couple of RFCs in a day. But this ease
of implementation means that for basically any issue where the specs give any
degree of freedom, somebody will have deviated from the norm. (I've
implemented TCP from scratch three times, one of those implementations
basically ran the traffic of entire countries.)

The real problem is that every step toward 100% gets progressively harder to
find and debug. See e.g. [0] for a middle box that would mangle connections if
it received two identical SYN packets, or [1] for a way in which almost all
servers anyone currently runs are accidentally resilient to a certain kind of
connection-killing packet corruption, but S3 isn't.

[0] [https://www.snellman.net/blog/archive/2014-11-11-tcp-is-
hard...](https://www.snellman.net/blog/archive/2014-11-11-tcp-is-harder-than-
it-looks.html) [1]
[https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/](https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/)

~~~
eatonphil
> You can implement something that can load a webpage from 99.9% of the
> world's web servers from a couple of RFCs in a day.

As an alternative perspective... while the RFCs are great, it's taken me weeks
(maybe months now) to hack together a not-yet-functional TCP/IP stack. I've
never dug below the application layer before. I'm still working through it. I
cannot even say if the RFCs are sufficient, but I'll take your word.

------
adwn
> _Its design anti-goals include complicated compile-time computations, such
> as macro or type tricks, even at cost of performance degradation._

Why? That sounds more like an ideological decision than a pragmatic,
engineering-driven one. Especially for a TCP/IP stack, where performance is
typically a major concern, be it in a desktop, server, or embedded
environment.

~~~
whitequark_
At the time when I started working on smoltcp, there were a few Rust libraries
for working with TCP/IP on the wire level, and they heavily used
metaprogramming. Unfortunately, the task of implementing a generic binary
protocol serializer/deserializer that can handle TCP/IP is not small, and as
far as I could tell, it overtook implementing anything beyond that.

So I made the decision to do the simplest possible thing: write the packet
serializers/deserializers entirely by hand. It took very little time and
adding any new features was easy and predictable. I believe it was the right
decision as it allowed me to focus on the hard parts of a TCP/IP stack.

~~~
adwn
Thank you for answering. That sounds sensible, I guess.

------
teddyh
Somewhat relatedly, there exists a Python-like language for when you only have
a few kb of memory, and can’t even run MicroPython. It’s called “Snek”:

[https://keithp.com/snek/](https://keithp.com/snek/)

------
blinkingled
You might not care for low level TCP/IP details but this project will make for
a great learning experience for anyone wanting to dig deeper into Rust and
network programming.

It works with tun/tap interfaces and there's a tcpdump clone in the example
using raw sockets that works on any regular Linux network interfaces.

Pretty cool!

------
Klasiaster
Here are memory-safe network services on Linux with smoltcp and an optional
switch for running multiple userspace network stacks:

[https://github.com/ANLAB-KAIST/usnet_sockets](https://github.com/ANLAB-
KAIST/usnet_sockets) → Socket library for Rust using smoltcp as userspace
network stack (provides types compatible with the standard library, tokio is
unpublished WIP)

[https://github.com/ANLAB-KAIST/usnetd](https://github.com/ANLAB-KAIST/usnetd)
→ Memory-safe L4 Switch for Userspace Network Stacks (firewalls the kernel
network stack, see Ideas section for alternatives, e.g., transparently piping
the kernel network packets through smoltcp)

------
pencillr
An educational question: If this is a tcp/ip implementation where is it run?
On a router? Or on a network interface controller? Both?

~~~
chaosite
"smoltcp is a standalone, event-driven TCP/IP stack that is designed for bare-
metal, real-time systems."

My understanding based on that description is that it is meant for
applications that run directly on the hardware, without an OS in the middle.
I'm thinking embedded applications.

So I'm thinking that this is meant for IoT-style appliances and the like.
Maybe I'm wrong :)

~~~
pencillr
Ah so, it can be something like a "network platform" on my (let's say) smart
home thermostat? :D

~~~
chaosite
Exactly, it can be the bit that allows your smart-home thermostat to talk to
the app on your phone (or the cloud).

------
kahlonel
Any idea what would it take to write this without using _any_ C library
function?

~~~
whitequark_
It doesn't use any C library functions by itself. (In fact in all of its
applications at M-Labs, there is no C code running on the same chip.)

The only uses of libc are in the TUN/TAP driver, which is necessary if you
want to bind it to a virtual OS interface.

------
gazarullz
Can anyone point out any resources to acomplish this in the JVM space?

~~~
gazarullz
Whoever downvoted my question can explain why? or it was just for fun?

~~~
smolder
I didn’t downvote you but running a TCP/IP stack inside the JVM doesn’t seem
terribly useful. Doing user space TCP/IP can be useful for performance reasons
but running on top of JVM is likely to wipe out that advantage.

------
nn3
>Congestion control is not implemented.

Wit that, don't bother with it so far. That's a toy. It would be dangerous on
any real network. If you doubt it please read up on "congestion collapse"

~~~
garmaine
Not sure why you are being down-voted. Congestion control is pretty central to
how TCP/IP works. Deploying without it will basically DoS your network.

------
fluffything
Lots of warnings on `cargo build`, undefined behavior on a couple of places
(e.g. crating &mut uninitialized), raw calls to libc as opposed to using a
safe wrapper over it like nix, ...

------
eeZah7Ux
What a poor choice for naming. Please don't use stupid internet memes for
naming, it makes all of us look silly in the eyes of non-techies.

~~~
WAHa_06x36
Are you expecting non-techies to be paying attention to an embedded TCP/IP
stack, and also worrying that they think you are having too much fun?

------
OskarS
Naming your product after dumb internet memes is a great way to make me not
want to use them.

Don’t get me wrong, from first look it seems like a perfectly fine product,
but the name is atrocious.

~~~
noselasd
For the uninitiated, which meme is this ?

~~~
toby-
It's part of DoggoLingo[0], a meme-filled Internet lexicon (or... something).
It's all in good fun, and I don't understand why anybody could be upset by it.
Sure, he could've called this "SmallTCP" and been bland, but decided to inject
some (silly) humour. Plenty of other projects are similarly named.[1]

It reminds me of the words "cromulent"[2] and "embiggen"[3]; coined by _The
Simpsons_ but used in everything from BBC articles to scientific research.

[0]:
[https://en.wikipedia.org/wiki/DoggoLingo](https://en.wikipedia.org/wiki/DoggoLingo)

[1]: [https://github.com/aras-p/smol-v](https://github.com/aras-p/smol-v)

[2]:
[https://en.wiktionary.org/wiki/cromulent](https://en.wiktionary.org/wiki/cromulent)

[3]:
[https://en.wiktionary.org/wiki/embiggen](https://en.wiktionary.org/wiki/embiggen)

~~~
NikkiA
> It reminds me of the words "cromulent"[2] and "embiggen"[3]; coined by The
> Simpsons but used in everything from BBC articles to scientific research.

 _popularized_ by the simpsons, at least cromulent was a valid english word
before the episode, I don't think embiggen was.

~~~
toby-
I don't think that's true. I can find no reference to "cromulent" existing
pre- _Simpsons_ , and every source explicitly says it was coined by David
Cohen for an episode.

From Wiktionary: "A humorous, intentionally morphologically opaque neologism
coined by American television writer David X. Cohen for 'Lisa the Iconoclast',
a 1996 episode of the animated sitcom The Simpsons."

From Merriam-Webster: "It is safe to say that The Simpsons has contributed a
great deal to the English language. One famous example is cromulent, which was
coined specifically for the 1996 episode 'Lisa the Iconoclast'."

