5 ms·

> I think there is a much more mundane lesson here. Good abstractions prevent entire classes of vulnerabilities This is how I try to write C, in the end there

> I think there is a much more mundane lesson here. Good abstractions prevent entire classes of vulnerabilities This is how I try to write C, in the end there there is very little "unsafe" code in it - few complicated pointer dereferences, few dynamic allocations, almost no transfer of ownership anywhere. No callbacks, and requiring e.g. a ref-counted handle is very rare. Mostly function calls, pointers only valid during function call (or make a copy, e.g. ID strings), creating the data in the module that understands it, using suitable allocation strategies and centralized resource release. Asynchronous messaging instead of hard to follow callbacks (which break the flow of execution). The current code I have has grown to be devoid of dynamic memory allocations simply for performance/latency reasons. It now has good MISRA compliance without ever trying hard. There have been a few bugs (including very silly and obvious concurrency bugs) but due to the app being so "fixed" those have always turned up pretty quickly (so far) and have been easy to spot and fix. For larger projects, I feel like the value of bottled abstractions is more and more decreasing. To connect things in an efficient and maintainable way all these layers have to be unwrapped.

dcow 5y ago
The Rust compiler essentially automates all this. Nobody is saying you can't write good C. The argument is that the data suggests a memory-safe language eliminates an entire realm of possibilities available in C. This is an attempt to push the general impression out of "hypothetically safe languages are safer" (which tends to be the talking point ad nauseam in language flame wars) to "we've established theory that safe languages empirically result in fewer CVEs by at least 65%". Safe Rust doesn't really let you introduce concurrency bugs either, which you admit show up even in well abstracted C.
- jstimpfle 5y ago
  > Safe Rust doesn't really let you introduce concurrency bugs either, which you admit show up even in well abstracted C. It was really obvious stuff that was immediately reproduced though. Related to a refactor taking into account some learnings that restricted concurrency almost to a single implementation file. My conjecture is that if code is littered with synchronization primitives, the structure is wrong. A system that automates the painful part of getting the use of synchronization primitives right is possibly rewarding bad structure, at least in the short term.
  - dcow 5y ago
    I think it really depends on the project/application. More often than not you should probably have a framework for handling concurrency (whether you've written it yourself or someone else), sure. But sometimes you find yourself writing/maintaining the framework, too. I've experienced times where, when writing concurrent code, I thought what I should be doing was okay because I would have done the same thing in C but Rust stepped in and said "actually I can't allow you to do that, Dave". I don't know if you've ever experienced something similar but it's pretty awesome when it happens.
    - jstimpfle 5y ago
      I don't disagree, TBH I find stuff like memory models kind of mind bending. Concurrency is easy to get wrong, that's why it might be best to avoid (centralize) it. That's what Golang did I think. I'm not up to date with a lot of the high-tech SMP stuff that is found in e.g. Linux - I'm sure they have a lot of direct memory sharing, I found sth in their Red-black tree for example, and for sure there a lot of spinlocks, schedule calls, and what not. I wonder if there has been a trend of turning back the explicit-synchronization dial a little, even there? It would make sense to me, memory has been becoming slower and slower (in terms of latency not performance, and relative to increasing CPU throughput), and there seems to be a trend for more asynchronous (non-blocking, message passing) stuff like io_uring.
      - tene 5y ago
        Could you explain a bit more about how you see Golang improving this? For me, Go is trickier to use concurrently than Rust, and requires keeping track of more details you need to manage yourself without compiler assistance or checking. For example, the default data structures like Map are not thread-safe, but you'll only discover that you've used a Map from multiple threads without synchronization when you actually have a concurrent modification at runtime, which might not show up at low load during testing. You're also responsible for explicitly locking (and unlocking) any synchronization primitives before accessing a synchronized resource, and ensuring you don't hold any references to synchronized data past the unlock. With Rust, this is all encoded in the APIs, and verified by either the type checker or the borrow checker. Since I need to deal with Golang at work, I've been trying to get less frustrated with it, so I'm really interested in hearing perspectives about what people appreciate about Golang, or what it does right or does well.
- kelnos 5y ago
  > Nobody is saying you can't write good C. I would say that, honestly. Or at least: I don't think anybody can reliably write non-trivial programs in C that 100% of the time avoid the kinds of memory-safety bugs that Rust protects against at compile-time. And that's what matters. Humans are fallible, and everyone makes mistakes sometimes.
  - UncleMeat 5y ago
    I 100% agree with this. I don't believe that a single human on the planet can write a nontrivial C program that processes untrusted input and contains no security vulnerabilities on their first attempt. And this is a much much much easier task than having a team develop and maintain such a system over time.
mike_hock 5y ago
Unfortunately, a large amount of code (even programs that are specifically built as a security feature), aren't written like that, so CVEs about banal buffer overruns and double frees that would have been trivial to prevent with proper abstractions keep popping up and somehow we think this is OK.

dcow 5y ago

The Rust compiler essentially automates all this. Nobody is saying you can't write good C. The argument is that the data suggests a memory-safe language eliminates an entire realm of possibilities available in C. This is an attempt to push the general impression out of "hypothetically safe languages are safer" (which tends to be the talking point ad nauseam in language flame wars) to "we've established theory that safe languages empirically result in fewer CVEs by at least 65%". Safe Rust doesn't really let you introduce concurrency bugs either, which you admit show up even in well abstracted C.

jstimpfle 5y ago
> Safe Rust doesn't really let you introduce concurrency bugs either, which you admit show up even in well abstracted C. It was really obvious stuff that was immediately reproduced though. Related to a refactor taking into account some learnings that restricted concurrency almost to a single implementation file. My conjecture is that if code is littered with synchronization primitives, the structure is wrong. A system that automates the painful part of getting the use of synchronization primitives right is possibly rewarding bad structure, at least in the short term.
- dcow 5y ago
  I think it really depends on the project/application. More often than not you should probably have a framework for handling concurrency (whether you've written it yourself or someone else), sure. But sometimes you find yourself writing/maintaining the framework, too. I've experienced times where, when writing concurrent code, I thought what I should be doing was okay because I would have done the same thing in C but Rust stepped in and said "actually I can't allow you to do that, Dave". I don't know if you've ever experienced something similar but it's pretty awesome when it happens.
  - jstimpfle 5y ago
    I don't disagree, TBH I find stuff like memory models kind of mind bending. Concurrency is easy to get wrong, that's why it might be best to avoid (centralize) it. That's what Golang did I think. I'm not up to date with a lot of the high-tech SMP stuff that is found in e.g. Linux - I'm sure they have a lot of direct memory sharing, I found sth in their Red-black tree for example, and for sure there a lot of spinlocks, schedule calls, and what not. I wonder if there has been a trend of turning back the explicit-synchronization dial a little, even there? It would make sense to me, memory has been becoming slower and slower (in terms of latency not performance, and relative to increasing CPU throughput), and there seems to be a trend for more asynchronous (non-blocking, message passing) stuff like io_uring.
    - tene 5y ago
      Could you explain a bit more about how you see Golang improving this? For me, Go is trickier to use concurrently than Rust, and requires keeping track of more details you need to manage yourself without compiler assistance or checking. For example, the default data structures like Map are not thread-safe, but you'll only discover that you've used a Map from multiple threads without synchronization when you actually have a concurrent modification at runtime, which might not show up at low load during testing. You're also responsible for explicitly locking (and unlocking) any synchronization primitives before accessing a synchronized resource, and ensuring you don't hold any references to synchronized data past the unlock. With Rust, this is all encoded in the APIs, and verified by either the type checker or the borrow checker. Since I need to deal with Golang at work, I've been trying to get less frustrated with it, so I'm really interested in hearing perspectives about what people appreciate about Golang, or what it does right or does well.
kelnos 5y ago
> Nobody is saying you can't write good C. I would say that, honestly. Or at least: I don't think anybody can reliably write non-trivial programs in C that 100% of the time avoid the kinds of memory-safety bugs that Rust protects against at compile-time. And that's what matters. Humans are fallible, and everyone makes mistakes sometimes.
- UncleMeat 5y ago
  I 100% agree with this. I don't believe that a single human on the planet can write a nontrivial C program that processes untrusted input and contains no security vulnerabilities on their first attempt. And this is a much much much easier task than having a team develop and maintain such a system over time.

mike_hock 5y ago

Unfortunately, a large amount of code (even programs that are specifically built as a security feature), aren't written like that, so CVEs about banal buffer overruns and double frees that would have been trivial to prevent with proper abstractions keep popping up and somehow we think this is OK.