Live data from Hacker News

Building my own network stack

blog.lyc8503.net

71–80 of 103 posts

Re: Building my own network stack

#71

The real nightmare scenario is not just finding a vulnerability in the Linux network stack but finding vulnerabilities at the protocol level in TCP/IP itself or HTTP. That’s a problem that cannot be fixed. Has there ever been a precedent for this in computing?

When these things come up, what usually happens is implementations stop following the spec as written.

Many issues can be handled with minimal coordination, but some things work much better with consensus and you see flag day campaigns. Ipv6 flag day had very limited impact on that day, but may restarted the process and actually got things moving. DNS flag days have been successful.

Re: Building my own network stack

#72
post #68

Earlier quoted context omitted.

I recently saw this guy on HN who had written a web server for an Atmel AVR and also implemented a TCP/IP stack to boot. It obviously was far from feature complete, but it did work. He used SLIP to communicate with the "server."

> far from feature complete, but it did work well that's the trick. If you look at implementing a Web browser or a physics engine you instantly give up, and you are right about it, it's just too hard. If instead you write a partial HTTP client which can display some text from a URL or have a 3D scene and in it an object Y coordinates get smaller each millisecond then suddenly in terms of the essence of each, you are…

I used to implement these things professionally and to write an IP + TCP + HTTP is certainly less than a year with experience. would I ship that and expect people to use it without a lot of burnin? no..but to say that its a lifetime of work is off by at least a factor of 10.

Re: Building my own network stack

#73
post #5

Earlier quoted context omitted.

I doubt it. It seems far more likely that such code will be written just once by LLMs, but in a way that allows its claimed guarantees to be formally verified (e.g. in Lean). At that point there’s no need to JIT an implementation each time.

My bet is one ultra-hardened, minimal, front-facing system which does N-modular redundancy which N systems, each written on a different stack/different language. The hardened software picks the computation that wins the majority. It's not an issue to write all the implementations in the various stacks/languages: we'll have better and better LLMs to help us. This shall bring security and shall allow to detect shitload…

I feel like that idea is erroneously mixing concepts. You want quorum in safety critical contexts, generally to guard against hardware failure. I think using independent implementations in such a scenario is uncommon and to date largely a stop gap to save money by replacing formal verification.

For security formal verification is really what you need. Both of the software and also eventually the hardware, since typically formal verification of software won't hold up against something like rowhammer. (Although TBF I'm not sure what sort of formal verification would have caught rowhammer.)

Re: Building my own network stack

#74

This article might be a bit tongue-in-cheek but it's actually something I've been thinking seriously about for a while. I can imagine a future where every country and company writes their own operating system and that might actually be a very good thing. There is a security advantage in not using popular technology stacks and rebuilding everything public-facing in-house. Because with Mythos-level AI capabilities, it…

This is the same erroneous reasoning as historical claims that FOSS was less secure due to being public. That has been disproven many times over by now.

The only way it might hold here is if no one with access to the cutting edge models bothers to run your code through one while an adversary does. That seems highly unlikely, particularly for any well funded organization.

That said I agree that monoculture is bad. Vulnerabilities like heartbleed or spectre are so devastating precisely because they apply to approximately everyone.

Re: Building my own network stack

#76
This kind of project is so much fun and a great learning exercise. While I respect the tongue-in-cheek proposition, we really would benefit from a wider understanding of network protocols. Doing an exercise like this is eye opening.

Re: Building my own network stack

#77
post #47

I would seriously recommend against building your own network stack for production use. Or writing your own web server for production use. Or database (whatever SQL or NoSQL) also for production use. These sort of things are more complicated than you could expect and have plentiful pitfalls. Whatever you can do in reasonable amount of time is probably not that good compared to existing alternatives. If you have actua…

Wanting to incorporate an http server into a C project of mine, the only battle-tested or feature-complete options either allocated dynamic memory UTH without an option to override the allocators, or are too opinionated with the core API, like mandating callbacks for everything. Suprisingly there's no decent (single header) C library that don't have these 2 issues, at least that I could find.

Re: Building my own network stack

#78

Earlier quoted context omitted.

Hah, the first engineering job I had was on Ovation DCS doing power plant controls. That system traces the lineage to the WDPF systems. Was the server you mention here the actual DCS? With the Motorola CPU's? Running vxworks? Pretty cool recognizing something niche that is still, vaguely familiar. :)

The plant computer wasn't a DCS. I think it was a DEC. It gathered data from the control systems and instrumentation and had a bespoke in memory realtime-ish database. That database was then partially replicated down to the Sun workstations (code the 23 year old me wrote). Then the browser consumed that via a unix shared memory interface.

Was it perhaps DEC Baseway[1] system? It would arguably qualify as a form of DCS, with central VAX servers and running high level software, PDP-11 "shop floor" computers, which in turn talked with PLCs and related devices.

And additionally, TCP/IP was an optional layered product - either DEC's own UCX (Ultrix Communication eXtensions) or 3rd party

[1] https://bitsavers.org/pdf/dec/vax/vms/baseway/

Re: Building my own network stack

#79

This is just an opinion and not a very sensible one at that. The Linux TCP/IP stack is one of the most scrutinized network stacks in the world and more than likely free of bugs that coud lead to a server takeover.

lols, what about the sendfile and other vulnerabilities that lasted decades. Linux just does not have a secure mentality, it has a hacker mentality, maybe acceptable for a lot of uses, but it is what it is.

Re: Building my own network stack

#80
post #19
post #6

Earlier quoted context omitted.

So do I. According to today’s prevalent tech/science culture, “everyone” should - write their own network stack, compiler, text editor, operating system - learn 3-5 foreign languages - travel extensively - learn how computers work from the silicon principles to the userspace - have a complete understanding of algorithms and data structures before even attempting to build anything, because nothing else will do - read…

What’s wrong with aspiring to do any or even all of those things? Those sound like nice things.

Where's the time left to actually live your life?
Post reply on HN