5 ms·
Yes, a TCP stack certainly is complex enough to warrant serious automated testing and/or TDD. The idea of putting the TCP stack in user space is interesting. I
by cjfd 5y ago
Yes, a TCP stack certainly is complex enough to warrant serious automated testing and/or TDD.
The idea of putting the TCP stack in user space is interesting. If one actually could map the memory of the whole device into user space one could maybe have fewer system calls and therefore have better performance.
Also, what I find somewhat irritating about using a linux system is how often one needs to run commands as root (sudo) for common administrative tasks like mounting a disk or stuff like that. Having a user space TCP stack could also decrease the need for that as far as setting up the network is concerned. If the linux machine is single user, as most of them are nowadays, it makes more sense that way, I think.
- rmetzler 5y ago> one needs to run commands as root (sudo) for common administrative tasks like mounting a disk I would think if you don't do this, an attacker who is able to execute code but is non-root yet could easily elevate permissions by shadowing legitimate pathes and trick root into executing untrusted code. I'm not a security engineer and just find it interesting, so if my thinking is off, please correct me.
- boomlinde 5y agoThere's nothing inherent about Linux which prevents you from running everything as uid 0. If you're fine with every process you run having the same full privileges and shared ownership of everything, you should. Most machines, at least outside embedded devices, are not like this. They are multi-user systems even when there's only ever one breathing thing at the desk because it offers a degree of separation between the privileges of your daemons, your pid 1, your web browser etc.
- heurisko 5y agoI think the point was that root shouldn’t be required for “common administrative tasks”. The nuclear option of running everything as root doesn’t address this.
- stingraycharles 5y agoWhat are the common administrative tasks related to networking that require root for networking? All I can think about is stuff like route tables and dhcp, both of which live at the IP/Ethernet level rather than TCP.
- adrian_b 5y agoStarting any network server process that uses ports under 1000, like most standard protocols (https, http, ssh, smtp, dns, ntp, dhcp etc.), requires root rights on any UNIX-like operating system. Most personal computers do not need server processes (unless you want to connect remotely to them), but your question was not restricted to them.
- boomlinde 5y agoFrom a practical point of view, regardless of the scope of the original question, this is the kind of scenario where you'd really want the restriction. More than a simple administrative task it's a dangerous attack vector to allow any user to launch your httpd or DNS. That being said, check out capabilities(7) in Linux. You can grant an executable the privilege of binding to a low port when run by non-0 uid through setcap. This is a good compromise.
- convolvatron 5y agothis whole 'privledged ports' nonsense is left over from a time where some process on another machine running on a low port was somehow to be trusted - because the person running that process was another administrator, and you can generally trust those guys (as opposed to unwashed users). that world didn't last very long, and I wish we could vent some of these designs that didn't pass the test of time.
- toast0 5y agoYou can adjust the highest priviledged port (at least on FreeBSD). It's convenient to set that to 79 and let regular users listen to http without needing root to listen. ssh and smtp generally need root to do their job, although maybe you could find a way to deliver mail to users without it. If you want to run user based dns or others, you could set the priviledged port even lower.
- stingraycharles 5y ago> Having a user space TCP stack could also decrease the need for [root privileges] as far as setting up the network is concerned. I think it’s important to distinguish between the protocol (TCP) and the hardware device. You would still absolutely need to talk to the device, it’s just that moving a lot of the logic to user space means much less context switching for system calls for the application. I can imagine on Linux you can talk directly to /dev/eth0 if you would want to (in the same way that you can talk to /dev/sda), and then you would be back at square one regarding root privileges.
- monocasa 5y ago> I can imagine on Linux you can talk directly to /dev/eth0 if you would want to (in the same way that you can talk to /dev/sda), and then you would be back at square one regarding root privileges. It's a AF_PACKET, SOCK_RAW socket rather than a device file, but yes.
- stefan_ 5y agoThe whole "map the PCIE device into userspace process memory" thing is called DPDK (https://www.dpdk.org/ https://www.dpdk.org/)
- ay 5y agoAnd you can combine the two: https://fd.io/docs/vpp/master/whatisvpp/hoststack.html https://fd.io/docs/vpp/master/whatisvpp/hoststack.html And there is a sister project using this tech to get noticeable speed-ups: https://wiki.fd.io/view/VSAP https://wiki.fd.io/view/VSAP Disclaimer: I am involved with the VPP project.
- avinassh 5y ago> The idea of putting the TCP stack in user space is interesting. Indeed! Julia Evans wrote a really nice post explaining the usecases and benefits - https://jvns.ca/blog/2016/06/30/why-do-we-use-the-linux-kernels-tcp-stack/ https://jvns.ca/blog/2016/06/30/why-do-we-use-the-linux-kern...
- yakubin 5y agoYou don't need to be root to mount disks, when you have udisks installed (which would be almost all distros by default). See udisksctl(1): <https://manpages.debian.org/buster/udisks2/udisksctl.1.en.html https://manpages.debian.org/buster/udisks2/udisksctl.1.en.ht...>