Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We improved the performance of a userspace TCP stack in Go

coder.com

Post reply on HN
Print view View original

101–110 of 133 posts

Re: We improved the performance of a userspace TCP stack in Go

#101

Post by kylecarbs »

santiagobasulto wrote: post #100
zxt_tzx wrote: post #90

I met one of the founders of Coder.com, he's a really cool dude. It's a pity that it is a product aimed more at enterprises than individual developers, else it would have far more developer mindshare. Unlike, say, GitHub Codespaces, running something like this on your own infra means your incentives and Coder.com's are aligned, i.e. both of you want to reduce your cloud costs (as opposed to, say, GitHub running on Az…

It seems like a great product. I'm wondering why they don't offer more "startup-oriented" plans. It's like either Self Hosted or "Talk to sales". Is it maybe to not compete against Github codespaces?

Founder of Coder here. Many small (or teams at big) companies use Coder for free with We’ve tried to align our pricing with the value of the product. In small teams the productivity gains seem to be much lower, so we target Enterprise!

Re: We improved the performance of a userspace TCP stack in Go

#102

Post by kylecarbs »

raggi wrote: post #60

It's great to see this, I know the team went on a long journey through this and the blog makes it almost look shorter and simpler than it was. I'm hoping one day we can all integrate the support for GSO that's been landing in gvisor too, but so far we've (tailscale) not had a chance to look deeply into that yet. It was really effective for our tun and UDP interfaces though.

At Coder we’re fans and users of Tailscale, so very happy to have these changes be consumed upstream as well!

Re: We improved the performance of a userspace TCP stack in Go

#103

Post by baq »

taeric wrote: post #84
tptacek wrote: post #69

Earlier quoted context omitted.

I'm not sure I can make this any simpler for you or easier to get your head around. If it helps: the idea here is giving an invocation of your program its own IP address . It can then do whatever it likes with TCP/IP for that address; its own routing, arbitrary protocols, whatever. The Go standard library makes it extremely easy to integrate. To the OS, it's all just ordinary socket code.

I think it is a valid question on why not use unprivileged ports, though? Or am I also missing something?

Number one reason is if you can't. Number two is if you don't want to.

You can't if your organization prevents you to, for example.

You don't want to if you follow strict rules which are not enforced by the OS, again for example.

Re: We improved the performance of a userspace TCP stack in Go

#104

Post by mort96 »

dave78 wrote: post #41
iangudger wrote: post #31

Earlier quoted context omitted.

If you want to use netstack without Bazel, just use the go branch: https://github.com/google/gvisor/tree/go go get gvisor.dev/gvisor/pkg/tcpip@go The go branch is auto generated with all of the generated code checked in.

I did this once for an experimental project and found it really difficult to keep the version of gVisor I was using up to date, since it seems like the API is extremely volatile. Anyone else had this experience? If so, is there some way around it that I don't know? Or did I just try it at a bad point in the development timeline?

That's just how Google operates in my experience... Avoid Google libraries unless absolutely necessary, and if you do adopt Google libraries, be prepared to either be forever multiple years out of date or spend significant resources on keeping it up to date.

Re: We improved the performance of a userspace TCP stack in Go

#105

Post by dgb23 »

mort96 wrote: post #104
dave78 wrote: post #41

Earlier quoted context omitted.

I did this once for an experimental project and found it really difficult to keep the version of gVisor I was using up to date, since it seems like the API is extremely volatile. Anyone else had this experience? If so, is there some way around it that I don't know? Or did I just try it at a bad point in the development timeline?

That's just how Google operates in my experience... Avoid Google libraries unless absolutely necessary, and if you do adopt Google libraries, be prepared to either be forever multiple years out of date or spend significant resources on keeping it up to date.

Plus those libraries are often very hard to read and understand. Maybe I'm just dense though.

Re: We improved the performance of a userspace TCP stack in Go

#106

Post by eqvinox »

tptacek wrote: post #17
wmf wrote: post #2

"Asking for elevated permissions inside secure clusters at regulated financial enterprises or top secret government networks is at best a big delay and at worst a nonstarter." But exfiltrating data with a userspace VPN is totally fine? I'm also wondering why not use TLS.

Every connection you make to a remote service "exfiltrates data". Modern TLS is just as opaque to middleboxes as WireGuard is, unless you add security telemetry directly to endpoints --- and then you don't care about the network anyways, so just monitor the endpoint. The reason you'd use WireGuard rather than TLS is that it allows you to talk directly to multiple services, using multiple protocols (most notably, thin…

Adding your own network stack to bypass limitations like this works exactly until the point where someone notices that your userspace stack needs to fulfill the same requirements that the host stack does.

And then you're suddenly in a whole world of pain because all of this is driven by a stack of byzantine certifications (half of which, as usual, are bogus, but that doesn't help you), and your network stack has none of them.

(Written from first-hand experience.)

Re: We improved the performance of a userspace TCP stack in Go

#107

Post by taeric »

baq wrote: post #103
taeric wrote: post #84

Earlier quoted context omitted.

I think it is a valid question on why not use unprivileged ports, though? Or am I also missing something?

Number one reason is if you can't. Number two is if you don't want to. You can't if your organization prevents you to, for example. You don't want to if you follow strict rules which are not enforced by the OS, again for example.

I'm curious why you couldn't?

And if you don't want to, that feels misguided?

Granted, my old recollection was largely that the "privileged" ports were that way because they were blessed by the routing tables, at the time. The entire point was that the lower ports were expected to be connectable to external machines. Not shocking if I am out of date there.

Re: We improved the performance of a userspace TCP stack in Go

#108

Post by baq »

taeric wrote: post #107
baq wrote: post #103

Earlier quoted context omitted.

Number one reason is if you can't. Number two is if you don't want to. You can't if your organization prevents you to, for example. You don't want to if you follow strict rules which are not enforced by the OS, again for example.

I'm curious why you couldn't? And if you don't want to, that feels misguided? Granted, my old recollection was largely that the "privileged" ports were that way because they were blessed by the routing tables, at the time. The entire point was that the lower ports were expected to be connectable to external machines. Not shocking if I am out of date there.

Both reasons have nothing to do with technical capability and everything with organisational policies.

Re: We improved the performance of a userspace TCP stack in Go

#109

Post by tptacek »

ahmedtd wrote: post #98
parhamn wrote: post #79

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=40591147 So the PaaS providers mentioned in that comment should be assumed to be compromised?

If they are using multitenant Docker / containerd containers with no additional sandboxing, then yes, then it's only a matter of time and attacker interest before a cross-tenant compromise occurs.

There isn't realistic sandboxing you can do with shared-kernel multitenant general-workload runtimes. You can do shared-kernel with a language runtime, like V8 isolates. You can do it with WASM. But you can't do native binary Unix execution and count on sandboxing to fix the security issues, because there's a track record of local LPEs in benign system calls.

Re: We improved the performance of a userspace TCP stack in Go

#110

Post by taeric »

baq wrote: post #108
taeric wrote: post #107

Earlier quoted context omitted.

I'm curious why you couldn't? And if you don't want to, that feels misguided? Granted, my old recollection was largely that the "privileged" ports were that way because they were blessed by the routing tables, at the time. The entire point was that the lower ports were expected to be connectable to external machines. Not shocking if I am out of date there.

Both reasons have nothing to do with technical capability and everything with organisational policies.

Right... but that just seems to imply that this is getting around policies by the letter?

I should hasten to add that I am not offering this as reason this shouldn't be done.

Post reply on HN