5 ms·

1) Many will cry about that performance hit (including me). For over a decade our computers have gotten faster marginally, but our software has gotten slower a

by dijit 4y ago

1) Many will cry about that performance hit (including me). For over a decade our computers have gotten faster marginally, but our software has gotten slower at a greater rate. You can barely navigate the web now with a new low end computer (that isn't a Chromebook). Most on this site won't care though because our machines cost $2,000+ and the web is Fine(tm); many folk aren't buying anything over $300 though. 2) These are memory bugs, so the introduction of Rust into the kernel could help us here potentially, no need for an architectural revolution.

boricj 4y ago
> Many will cry about that performance hit (including me) because for over a decade our computers have gotten faster marginally, but our software has gotten slower and bloatier at an increasingly rapid pace. We're talking about network stacks and network drivers, not web browsers. Migrating the network stack from the kernel to a user-land process is not going to measurably slow down web browsers, especially on modern systems with gigabytes of RAM, multiple cores, IOMMUs and whatnots. > These are memory bugs, so the introduction of Rust into the kernel could help us here potentially, no need for an architectural revolution. That would require rewriting the network stack and network drivers in Rust (driver code is much more likely to have bugs than the rest of the kernel) for this to be effective, otherwise you'll still have a lot of C code in the network path. I'd argue that this would be a bigger architectural revolution than porting the existing code and running it in user-land. MINIX3 went through such a change when drivers were removed from the kernel (can't find the publication about it right now) and they only required reasonably small changes when porting these to user-land, there were not rewritten from scratch. But this is not just about memory safety, Rust code can still be vulnerable in many other ways (memory leaks, unsafe blocks, wrong assumptions, incorrect algorithm implementation, buggy/compromised toolchains...). Code running inside the trusted computing base of a system is a liability, enforcing privilege separation and principle of least authority reduces it.
- dijit 4y ago
  > We're talking about network stacks and network drivers, not web browsers. Ah yes, the magic web-browser that doesn't do any kind of networking at all. > Migrating the network stack from the kernel to a user-land process is not going to measurably slow down web browsers, especially on modern systems with IOMMUs and whatnots. I don't know how you can possibly assert that, it's contradicting computer sciences' current understanding of operating system design as it relates to kernelmode/usermode switching, unless you're doing weird shared-memory things in userspace... which is terrifying. > That would require rewriting the network stack and network drivers in Rust Not really, C and Rust can interop just fine, you can have network drivers that are rust but the actual networking stack itself can remain C, if you want. > but this is not just about memory safety, Rust code can still be vulnerable in many other ways The post is literally memory safety bugs.
  - detaro 4y ago
    > Ah yes, the magic web-browser that doesn't do any kind of networking at all. They clearly didn't claim that. Your webbrowser being slow nowadays is not because it needs to do some networking.
    - dijit 4y ago
      They are claiming a loss in performance is ok. I am claiming that people keep making this claim and it no longer holds true because software is already losing too much performance for the value we get back. That's my whole thesis.
      - jjnoakes 4y ago
        Your claim assumes that a small loss in performance in networking will lead to a loss in performance of the overall web browser, which is only true if networking is the bottleneck while browsing. And it usually isn't.
        dijit 4y ago
        Ah, so you think the only thing I do with a computer is use the browser? That's weird, I was just making an example of something that is so slow that is literally unworkable in the modern day already. Impacting networking affects the entire machine, especially in so far as a computer is increasingly just a dumb terminal to something else. Look, If you make network requests potentially 20% slower then the browser performance will be impacted too, it's so obvious that I'm not sure how I can explain it simpler. By how much? I am not sure, but you can't say it won't be slower at all unless we're talking about magic. Pretending that it's trivial amounts of performance drop without evidence is the wrong approach. Show me how you can have similar performance with 20% increase in latency and I will change my stance here. As it stands there are two things I know to be true: Browsers rely on networking (as do many things, btw) and software is increasingly slow to provide similar value these days.
- throw10920 4y ago
  > I'd argue that this would be a bigger architectural revolution than porting the existing code and running it in user-land. MINIX3 went through such a change MINIX is a microkernel architecture - running drivers in userspace is one of its core features/selling points, and one that differentiates it from (modular) monolithic kernels such as Linux. So, this isn't a very solid line of reasoning. It seems to me that the situation is the opposite - that moving drivers to userspace is an architectural change, which is more complex than porting an existing architecture to a new language. > Rust code can still be vulnerable in many other ways Sure, but not vulnerable in the way that the vulnerability under discussion is. > memory leaks Much harder in Rust than C, and also unlike in C, not going to result in security vulnerabilities. > buggy/compromised toolchains If you're going to assume that your toolchain is compromised, than anything is on the table, including the toolchain inserting a backdoor into the kernel and completely bypassing the proposed architectural change of moving drivers into user-space. And, needless to say, compiler bugs are rare in general, and compiler bugs that cause software vulnerabilities are nearly unheard of (and I've literally never seen one before). Nobody thinking rationally is going to tell you that Rust is going to eliminate all your bugs or make your code secure. However, by far, the majority of security bugs in the Linux kernel are due to mistakes that the design of Rust either completely eliminates or massively reduces. And security is intrinsically a tradeoff - the Linux kernel is not optimized for maximum security (which would be something formally-verified like seL4), but a compromise between security, performance, and development velocity. The claim is that Rust will provide significantly better security at basically the same performance and possibly modestly improved development velocity - the very least that one should do is rewrite the existing architecture in it (or, again, a language that meets or exceeds the specs of Rust) and then see what the bug rate is before deciding to take a guaranteed performance hit through an architectural change.
  - boricj 4y ago
    > MINIX is a microkernel architecture - running drivers in userspace is one of its core features/selling points, and one that differentiates it from (modular) monolithic kernels such as Linux. So, this isn't a very solid line of reasoning. The first two versions of MINIX ran drivers inside the context of the kernel. The migration of drivers to user-space and overall emphasis on reliability didn't happen before MINIX3 in 2006. Given that Linux nowadays has FUSE and UIO, still calling it a strictly monolithic kernel is probably a bit of a misnomer at this point. The same goes for Windows, NetBSD and others by the way. > It seems to me that the situation is the opposite - that moving drivers to userspace is an architectural change, which is more complex than porting an existing architecture to a new language. Trying to do a straightforward port of a C code base to Rust will quickly grind to a halt due to Rust's borrow checker. On a highly-optimized code base such as the Linux network stack, untangling every last optimization trick and shortcut to make the Rust compiler happy would require a large-scale refactoring that'll end up looking nothing like the original code base, at which point you might as well rewrite it from scratch. In comparison, migrating that C code base to user-land would be less of a disruptive change to the code base (as was the case when MINIX3 did so with its drivers). It's still the same old network stack, adapted to run on a different environment. > Sure, but not vulnerable in the way that the vulnerability under discussion is. Rust isn't a silver bullet against every class of bug. Code that runs inside the trusted computing base means that it's one security bug away from system compromise. Writing that code in Rust doesn't change that.
binkHN 4y ago
> You can barely navigate the web now with a new low end computer... You can barely navigate the web now with almost any computer. I have a high-end laptop and opening a few tabs from various sites on the Internet will cause the CPU usage and fan speed to spike. Just for a few tabs! Obviously not all sites do this, but the web has become a framework of advertising monstrosity and I can barely navigate and consume much of today's web content without enabling Reader Mode.
photochemsyn 4y ago
Well, you can navigate the web with older low end computers if you're running the full suite of blockers (NoScript & UBlock on Firefox seems to work pretty well), but that means many sites don't work unless you selectively allow certain scripts to work by fiddling with NoScript permissions and selective blocking some elements with Ublock. HTML + CSS sites are no problem, however.
throwaway894345 4y ago
How do the micro kernel folks get around this? Are they paying the syscall toll between kernel components?
- dijit 4y ago
  Yes, exactly! Redox-OS is based on this approach and is honestly extremely clean and easy to understand (when compared to MINIX which also adopts the same approach). Wikipedia has a much better explanation than I can give right now: https://en.wikipedia.org/wiki/Microkernel#Performance https://en.wikipedia.org/wiki/Microkernel#Performance
- yjftsjthsd-h 4y ago
  > How do the micro kernel folks get around this? AIUI, in general, they don't. Avoiding the overhead of context switches is the research question in microkernels, and while there is progress being made, last I'd heard there wasn't a solution that didn't carry caveats. Now to be fair, sometimes those caveats are fine - ex. if you only write software in rust maybe you can get away with actually passing around memory without copies - but often they undermine the ability to run arbitrary software on general purpose hardware. (If I'm behind and this has been solved in the general case, I'm happy to be corrected, but this was my undestanding of things as of a few years ago and I haven't heard about a breakthrough)
miclill 4y ago
Regarding the first point. If I understand correctly you say that there is an inevitable performance hit when not running in kernel mode. But is that really so?
- dijit 4y ago
  I don't like that you were downvoted for curiosity. Yes, there is a performance hit but how large it is depends a lot on what you're doing. "Switching" is one of the most costly operations and in Kernel mode you do not need to do it unless interacting with something in user space.. which you would only do because something in Userspace requested it somehow. For other things, such as virtual memory, Microsoft found that the protections needed for virtual memory could be anywhere between 10 and 20%; but since there's no concept of virtual memory in kernel space: it's hard to say concretely that your program would be "20% faster". It would be too much of a different program.
  - galangalalgol 4y ago
    The whole point of dpdk is that it bypasses the kernel to obtain speed. It almost certainly requires a lot of privileges, but the kernel itself isn't the source of the hit.
    - gpderetta 4y ago
      The cost is in the switch between driver->kernel->network-consumer as running TCP and routing packets to the correct process are done by the kernel. If you run dpdk you get raw ethernet frames and run TCP yourself. This means that a program can receive any data sent to the machine. More sophisticate cards can do routing in hardware and present multiple "virtual" cards, but this is not yet commonly available in consumer hardware.
    - dijit 4y ago
      dpdk is not general purpose networking. It's passing a device to a process and forgetting about it; the process itself needs to decode what is sent on the wire and make sense of it. It's basically the kernel giving up on trying to do anything with the hardware, thus it's not available to any other process except the one that takes the hardware. To have general purpose networking in user space you will end up with some other IPC which does not rely on sockets (because sockets are kernel) or shared memory which is dangerous as hell.
loudmax 4y ago
A faster network is going to have a marginal effect on software getting slower. There are a lot of factors at play: network speed, cpu power, local caches, etc. The speed of the network driver is one factor among many and I'd be surprised if were the most common bottleneck. The operators of websites that derive most of their revenue from advertising are going to run their sites at whatever level users will tolerate. Where network drivers are faster they'll either cram in more ad tracking, or won't bother optimizing their existing trackers. If users stop accessing sites because they're too slow to load, operators will either cut down on ad tracking, or more likely, put some effort into optimizing the performance of their ad trackers. Rust is itself something of an architectural revolution. I believe network drivers in userspace is already a thing, and eBPF may also have a role here. All of this is worth exploring. This is what progress in Linux looks like.
- dijit 4y ago
  > A faster network is going to have a marginal effect on software getting slower. I don't mean to be glib but: citation needed? One of the slowest moving hardware improvements (compared to CPU/Memory speeds) is networking. It's going to take some serious convincing to tell me that we should just fork off performance; when software is already getting slower and slower. It's not fair to blame advertisers exclusively, we also have electron and the hundreds of JS frameworks, that's before we get down to the low level abstractions that hook into basic programs.
  - tjoff 4y ago
    The network stack isn't written in javascript. The slowness of the web will not get any worse by moving the network stack to userspace. Guaranteed.
    - dijit 4y ago
      You have the entire body of computer science research around microkernels against you here. What has changed?
devwastaken 4y ago
This is driver software, not relevant. Rust isn't a magic spell to be thrown out there when traditional solutions work quite well. The old reasons for hard kernel/userland separation are far less reasonable now.
mike_hock 4y ago
1) For this very reason, it doesn't make sense to optimize low-level components from the OS down to the hardware anymore, and hasn't for over a decade, if an improved user experience is your goal. The short-term effect may be a slight improvement, but it's a treadmill and the next wave of web crapware will more than nullify it. If a microkernel architecture with worse performance got established on all mainstream devices, the experience would be worse in the short term but in the medium term, the crapware would have to adapt so that it again becomes just barely usable as it is today. The problem is that the short-term gains create an incentive for users to buy/use the marginally faster hardware or kernel, which then forces everyone else to follow suit.
amelius 4y ago
> Many will cry about that performance hit (including me). Ok, we could make it optional, i.e. additional security for those who wish it (on top of other things we could do, like the things you mentioned but which aren't a panacea too).

by dijit 4y ago

boricj 4y ago

> Many will cry about that performance hit (including me) because for over a decade our computers have gotten faster marginally, but our software has gotten slower and bloatier at an increasingly rapid pace. We're talking about network stacks and network drivers, not web browsers. Migrating the network stack from the kernel to a user-land process is not going to measurably slow down web browsers, especially on modern systems with gigabytes of RAM, multiple cores, IOMMUs and whatnots. > These are memory bugs, so the introduction of Rust into the kernel could help us here potentially, no need for an architectural revolution. That would require rewriting the network stack and network drivers in Rust (driver code is much more likely to have bugs than the rest of the kernel) for this to be effective, otherwise you'll still have a lot of C code in the network path. I'd argue that this would be a bigger architectural revolution than porting the existing code and running it in user-land. MINIX3 went through such a change when drivers were removed from the kernel (can't find the publication about it right now) and they only required reasonably small changes when porting these to user-land, there were not rewritten from scratch. But this is not just about memory safety, Rust code can still be vulnerable in many other ways (memory leaks, unsafe blocks, wrong assumptions, incorrect algorithm implementation, buggy/compromised toolchains...). Code running inside the trusted computing base of a system is a liability, enforcing privilege separation and principle of least authority reduces it.

dijit 4y ago
> We're talking about network stacks and network drivers, not web browsers. Ah yes, the magic web-browser that doesn't do any kind of networking at all. > Migrating the network stack from the kernel to a user-land process is not going to measurably slow down web browsers, especially on modern systems with IOMMUs and whatnots. I don't know how you can possibly assert that, it's contradicting computer sciences' current understanding of operating system design as it relates to kernelmode/usermode switching, unless you're doing weird shared-memory things in userspace... which is terrifying. > That would require rewriting the network stack and network drivers in Rust Not really, C and Rust can interop just fine, you can have network drivers that are rust but the actual networking stack itself can remain C, if you want. > but this is not just about memory safety, Rust code can still be vulnerable in many other ways The post is literally memory safety bugs.
- detaro 4y ago
  > Ah yes, the magic web-browser that doesn't do any kind of networking at all. They clearly didn't claim that. Your webbrowser being slow nowadays is not because it needs to do some networking.
  - dijit 4y ago
    They are claiming a loss in performance is ok. I am claiming that people keep making this claim and it no longer holds true because software is already losing too much performance for the value we get back. That's my whole thesis.
    - jjnoakes 4y ago
      Your claim assumes that a small loss in performance in networking will lead to a loss in performance of the overall web browser, which is only true if networking is the bottleneck while browsing. And it usually isn't.
      - dijit 4y ago
        Ah, so you think the only thing I do with a computer is use the browser? That's weird, I was just making an example of something that is so slow that is literally unworkable in the modern day already. Impacting networking affects the entire machine, especially in so far as a computer is increasingly just a dumb terminal to something else. Look, If you make network requests potentially 20% slower then the browser performance will be impacted too, it's so obvious that I'm not sure how I can explain it simpler. By how much? I am not sure, but you can't say it won't be slower at all unless we're talking about magic. Pretending that it's trivial amounts of performance drop without evidence is the wrong approach. Show me how you can have similar performance with 20% increase in latency and I will change my stance here. As it stands there are two things I know to be true: Browsers rely on networking (as do many things, btw) and software is increasingly slow to provide similar value these days.
throw10920 4y ago
> I'd argue that this would be a bigger architectural revolution than porting the existing code and running it in user-land. MINIX3 went through such a change MINIX is a microkernel architecture - running drivers in userspace is one of its core features/selling points, and one that differentiates it from (modular) monolithic kernels such as Linux. So, this isn't a very solid line of reasoning. It seems to me that the situation is the opposite - that moving drivers to userspace is an architectural change, which is more complex than porting an existing architecture to a new language. > Rust code can still be vulnerable in many other ways Sure, but not vulnerable in the way that the vulnerability under discussion is. > memory leaks Much harder in Rust than C, and also unlike in C, not going to result in security vulnerabilities. > buggy/compromised toolchains If you're going to assume that your toolchain is compromised, than anything is on the table, including the toolchain inserting a backdoor into the kernel and completely bypassing the proposed architectural change of moving drivers into user-space. And, needless to say, compiler bugs are rare in general, and compiler bugs that cause software vulnerabilities are nearly unheard of (and I've literally never seen one before). Nobody thinking rationally is going to tell you that Rust is going to eliminate all your bugs or make your code secure. However, by far, the majority of security bugs in the Linux kernel are due to mistakes that the design of Rust either completely eliminates or massively reduces. And security is intrinsically a tradeoff - the Linux kernel is not optimized for maximum security (which would be something formally-verified like seL4), but a compromise between security, performance, and development velocity. The claim is that Rust will provide significantly better security at basically the same performance and possibly modestly improved development velocity - the very least that one should do is rewrite the existing architecture in it (or, again, a language that meets or exceeds the specs of Rust) and then see what the bug rate is before deciding to take a guaranteed performance hit through an architectural change.
- boricj 4y ago
  > MINIX is a microkernel architecture - running drivers in userspace is one of its core features/selling points, and one that differentiates it from (modular) monolithic kernels such as Linux. So, this isn't a very solid line of reasoning. The first two versions of MINIX ran drivers inside the context of the kernel. The migration of drivers to user-space and overall emphasis on reliability didn't happen before MINIX3 in 2006. Given that Linux nowadays has FUSE and UIO, still calling it a strictly monolithic kernel is probably a bit of a misnomer at this point. The same goes for Windows, NetBSD and others by the way. > It seems to me that the situation is the opposite - that moving drivers to userspace is an architectural change, which is more complex than porting an existing architecture to a new language. Trying to do a straightforward port of a C code base to Rust will quickly grind to a halt due to Rust's borrow checker. On a highly-optimized code base such as the Linux network stack, untangling every last optimization trick and shortcut to make the Rust compiler happy would require a large-scale refactoring that'll end up looking nothing like the original code base, at which point you might as well rewrite it from scratch. In comparison, migrating that C code base to user-land would be less of a disruptive change to the code base (as was the case when MINIX3 did so with its drivers). It's still the same old network stack, adapted to run on a different environment. > Sure, but not vulnerable in the way that the vulnerability under discussion is. Rust isn't a silver bullet against every class of bug. Code that runs inside the trusted computing base means that it's one security bug away from system compromise. Writing that code in Rust doesn't change that.

binkHN 4y ago

> You can barely navigate the web now with a new low end computer... You can barely navigate the web now with almost any computer. I have a high-end laptop and opening a few tabs from various sites on the Internet will cause the CPU usage and fan speed to spike. Just for a few tabs! Obviously not all sites do this, but the web has become a framework of advertising monstrosity and I can barely navigate and consume much of today's web content without enabling Reader Mode.

photochemsyn 4y ago

Well, you can navigate the web with older low end computers if you're running the full suite of blockers (NoScript & UBlock on Firefox seems to work pretty well), but that means many sites don't work unless you selectively allow certain scripts to work by fiddling with NoScript permissions and selective blocking some elements with Ublock. HTML + CSS sites are no problem, however.

throwaway894345 4y ago

How do the micro kernel folks get around this? Are they paying the syscall toll between kernel components?

dijit 4y ago
Yes, exactly! Redox-OS is based on this approach and is honestly extremely clean and easy to understand (when compared to MINIX which also adopts the same approach). Wikipedia has a much better explanation than I can give right now: https://en.wikipedia.org/wiki/Microkernel#Performance https://en.wikipedia.org/wiki/Microkernel#Performance
yjftsjthsd-h 4y ago
> How do the micro kernel folks get around this? AIUI, in general, they don't. Avoiding the overhead of context switches is the research question in microkernels, and while there is progress being made, last I'd heard there wasn't a solution that didn't carry caveats. Now to be fair, sometimes those caveats are fine - ex. if you only write software in rust maybe you can get away with actually passing around memory without copies - but often they undermine the ability to run arbitrary software on general purpose hardware. (If I'm behind and this has been solved in the general case, I'm happy to be corrected, but this was my undestanding of things as of a few years ago and I haven't heard about a breakthrough)

miclill 4y ago

Regarding the first point. If I understand correctly you say that there is an inevitable performance hit when not running in kernel mode. But is that really so?

dijit 4y ago
I don't like that you were downvoted for curiosity. Yes, there is a performance hit but how large it is depends a lot on what you're doing. "Switching" is one of the most costly operations and in Kernel mode you do not need to do it unless interacting with something in user space.. which you would only do because something in Userspace requested it somehow. For other things, such as virtual memory, Microsoft found that the protections needed for virtual memory could be anywhere between 10 and 20%; but since there's no concept of virtual memory in kernel space: it's hard to say concretely that your program would be "20% faster". It would be too much of a different program.
- galangalalgol 4y ago
  The whole point of dpdk is that it bypasses the kernel to obtain speed. It almost certainly requires a lot of privileges, but the kernel itself isn't the source of the hit.
  - gpderetta 4y ago
    The cost is in the switch between driver->kernel->network-consumer as running TCP and routing packets to the correct process are done by the kernel. If you run dpdk you get raw ethernet frames and run TCP yourself. This means that a program can receive any data sent to the machine. More sophisticate cards can do routing in hardware and present multiple "virtual" cards, but this is not yet commonly available in consumer hardware.
  - dijit 4y ago
    dpdk is not general purpose networking. It's passing a device to a process and forgetting about it; the process itself needs to decode what is sent on the wire and make sense of it. It's basically the kernel giving up on trying to do anything with the hardware, thus it's not available to any other process except the one that takes the hardware. To have general purpose networking in user space you will end up with some other IPC which does not rely on sockets (because sockets are kernel) or shared memory which is dangerous as hell.

loudmax 4y ago

A faster network is going to have a marginal effect on software getting slower. There are a lot of factors at play: network speed, cpu power, local caches, etc. The speed of the network driver is one factor among many and I'd be surprised if were the most common bottleneck. The operators of websites that derive most of their revenue from advertising are going to run their sites at whatever level users will tolerate. Where network drivers are faster they'll either cram in more ad tracking, or won't bother optimizing their existing trackers. If users stop accessing sites because they're too slow to load, operators will either cut down on ad tracking, or more likely, put some effort into optimizing the performance of their ad trackers. Rust is itself something of an architectural revolution. I believe network drivers in userspace is already a thing, and eBPF may also have a role here. All of this is worth exploring. This is what progress in Linux looks like.

dijit 4y ago
> A faster network is going to have a marginal effect on software getting slower. I don't mean to be glib but: citation needed? One of the slowest moving hardware improvements (compared to CPU/Memory speeds) is networking. It's going to take some serious convincing to tell me that we should just fork off performance; when software is already getting slower and slower. It's not fair to blame advertisers exclusively, we also have electron and the hundreds of JS frameworks, that's before we get down to the low level abstractions that hook into basic programs.
- tjoff 4y ago
  The network stack isn't written in javascript. The slowness of the web will not get any worse by moving the network stack to userspace. Guaranteed.
  - dijit 4y ago
    You have the entire body of computer science research around microkernels against you here. What has changed?

devwastaken 4y ago

This is driver software, not relevant. Rust isn't a magic spell to be thrown out there when traditional solutions work quite well. The old reasons for hard kernel/userland separation are far less reasonable now.

mike_hock 4y ago

1) For this very reason, it doesn't make sense to optimize low-level components from the OS down to the hardware anymore, and hasn't for over a decade, if an improved user experience is your goal. The short-term effect may be a slight improvement, but it's a treadmill and the next wave of web crapware will more than nullify it. If a microkernel architecture with worse performance got established on all mainstream devices, the experience would be worse in the short term but in the medium term, the crapware would have to adapt so that it again becomes just barely usable as it is today. The problem is that the short-term gains create an incentive for users to buy/use the marginally faster hardware or kernel, which then forces everyone else to follow suit.

amelius 4y ago

> Many will cry about that performance hit (including me). Ok, we could make it optional, i.e. additional security for those who wish it (on top of other things we could do, like the things you mentioned but which aren't a panacea too).