11 ms·

Can you pass this buffer to e.g. read() and it will still guarantee no buffer overflow even if the programmer mis-calculate the size argument to read() ?

falcolas 10y ago
You can with fixed sized buffers; the size passed to read() would be constant. I'd argue that for programs such as NTP, avoiding dynamic allocations on heap is not such a terrible goal.
lacampbell 10y ago
No. It then follows that reading things safely is therefore a completely insurmountable problem in C. There is no possible way for me thin wrapper around read that works on bounds checked arrays, and not use "read" cavalierly in my code without thinking. Right?
- Animats 10y ago
  The track record of two decades of CERT advisories for buffer overflows suggests that doesn't work in practice.
  - lacampbell 10y ago
    Just because people fail to do something doesn't mean it's not both possible and easy.
    - staticassertion 10y ago
      While this is technically true, it isn't practically true. "Easy" is certainly false. I really enjoyed these posts by strncat: https://www.reddit.com/r/programming/comments/5krztf/rust_vs_c_pitfalls/dbr7d7u/?context=3 https://www.reddit.com/r/programming/comments/5krztf/rust_vs... > It's scary how unfamiliar C programmers are with the rules of the language they're using... it's very difficult to write correct / secure C code without undefined behavior even when you know the rules. [...] > It's not feasible to avoid undefined behavior at scale in C or C++ projects. It's simply infeasible. They are not usable as safe tools without using a very constrained dialect of the languages where nearly all real world code would be treated as invalid, with annotations required to prove things to the compiler and communicate information about APIs to it.
    - pjmlp 10y ago
      I have been hearing and reading that from C advocates since 1993. It only got worse.
      - lacampbell 10y ago
        Not an argument, or even a point. I don't know why this is so difficult for people to understand. Buffer overflows are easy to avoid in C. I think I recognise your name from some rather aggressive rust advocacy in another thread, so I'll try and break this down in a way that won't trigger you: - Buffer overflows are trivial to avoid in Rust, AFAIK. I acknowledge this - Buffer overflows are very easy to code in C, and have occurred many times in the wild. Again, I acknowledge this. - My argument is - buffer overflows are easily preventable in C if you provide your own thin abstractions. The fact that people don't take these steps doesn't mean that these steps cannot be taken. Take the rust compiler itself: AFAIK it's now implemented in C++, an 'unsafe' language, and YET it manages to provide in abstraction in the form of a language that makes buffer overflows all but impossible. Do you understand now how it's possible create a safe abstractions in an unsafe language?
        cwyers 10y ago
        > Do you understand now how it's possible create a safe abstractions in an unsafe language? Who cares? What's "possible" is completely besides the point. What matters what is done. And so, yes, you can create safe abstractions in C. But if you need to interoperate with someone else's C code, you have to deal with how your abstractions interact with someone else's, or someone else's lack of them. The point of using a language like Rust or Go or... pretty much any non-C language with lots of traction is that you don't have to provide "your own thin abstractions." You use the same one as everyone else. The point of Rust or Go isn't to make things easier on you. It's to protect you from every other piece of code you interact with. The standard library. Libraries written in the language. Other people working on the same project as you. Yourself five weeks ago. You all use the SAME safe abstraction. Nobody has to roll their own. There aren't 25 safe abstractions for 20 people working on the project. You don't have to reason out or guess whether or not some library (or even the standard library) is doing the right thing to avoid buffer overrun. You don't need to defend your entire codebase against someone else's code not doing the right thing.
    - simondedalus 10y ago
      obviously decades of security advisories means it's not easy. what in the world does 'easy' mean in your current usage? surely "tons of failures" is a better indicator of difficulty than "it feels easy to me / that's 'naturally how my brain works'," etc. and of course, if lots of people fail at something, it will get proportionally harder with a larger team / larger codebase / different stakeholders demanding xyz, etc etc etc. not chiming in about the basic disagreements in this thread, but the repeated claim that something that has caused trouble for countless professionals is "easy" just can't be right. if all the qualified people are "unqualified" because they all fail at something "everyone can do," the speaker is the one who's confused, and it's a lexical problem.
      - lacampbell 10y ago
        I never said everyone could do it. But a competent C programmer definitely can. I suppose I am an elitist in the sense that I don't think novice or careless programmers should be writing production code. I mean people manage to do a lot of dangerous things due to sloppiness - cause car accidents, for example. I don't think it's hard to avoid that, and I don't think those people should be driving. I suppose others think we need wider roads and bumper cars.
civility 10y ago
I'll bet he can give you an array_read() function that does what you ask. I know I could.
- deleted 10y ago
  [deleted]
- lacampbell 10y ago
  The fact that it doesn't occur to people to build safe abstractions in C to deal with things like buffer overflows still shocks me. C is fairly low level by todays standards. You 100% have to build abstractions using the standard library and then use those abstractions, rather than just using standard library functions everywhere. This isn't an argument against safer languages, or higher level languages, or languages with built in bounds checking or anything else. This is more an argument against programming in a "close to the metal" language like C so thoughtlessly that buffer overflows are actually a serious issue. Maybe you just need a pedantic mind. When first learning C, as soon as I figured out that writing "char buffer[BUFFER_LEN];" could cause your program to crash, I immediately set out to write a safe dynamic array implementation I could push chars onto it and I didn't have to worry. And I am by no means an expert C programmer.
  - munin 10y ago
    Is this abstraction zero-cost? What's the overhead? Can you give me a similar set of primitives to manipulate memory in a temporally safe manner as well? What is the cost of that abstraction? How does it compare to a runtime's GC?
    - civility 10y ago
      > Is this abstraction zero-cost? What's the overhead? It will cost a single correctly predicted branch, which is effectively free on modern architectures. Any "safe" language will have to make this conditional branch too (Rust's File::read method will check the size of the slice).
      - 10y ago
imtringued 10y ago
Sure, if the array index is limited to 32 or 16 or 8 bits I can also give it to you at no performance cost for heap allocated arrays (i.e. no bound check happen at runtime). There is some memory overhead per array with this method though.

falcolas 10y ago

You can with fixed sized buffers; the size passed to read() would be constant. I'd argue that for programs such as NTP, avoiding dynamic allocations on heap is not such a terrible goal.

lacampbell 10y ago

No. It then follows that reading things safely is therefore a completely insurmountable problem in C. There is no possible way for me thin wrapper around read that works on bounds checked arrays, and not use "read" cavalierly in my code without thinking. Right?

Animats 10y ago
The track record of two decades of CERT advisories for buffer overflows suggests that doesn't work in practice.
- lacampbell 10y ago
  Just because people fail to do something doesn't mean it's not both possible and easy.
  - staticassertion 10y ago
    While this is technically true, it isn't practically true. "Easy" is certainly false. I really enjoyed these posts by strncat: https://www.reddit.com/r/programming/comments/5krztf/rust_vs_c_pitfalls/dbr7d7u/?context=3 https://www.reddit.com/r/programming/comments/5krztf/rust_vs... > It's scary how unfamiliar C programmers are with the rules of the language they're using... it's very difficult to write correct / secure C code without undefined behavior even when you know the rules. [...] > It's not feasible to avoid undefined behavior at scale in C or C++ projects. It's simply infeasible. They are not usable as safe tools without using a very constrained dialect of the languages where nearly all real world code would be treated as invalid, with annotations required to prove things to the compiler and communicate information about APIs to it.
  - pjmlp 10y ago
    I have been hearing and reading that from C advocates since 1993. It only got worse.
    - lacampbell 10y ago
      Not an argument, or even a point. I don't know why this is so difficult for people to understand. Buffer overflows are easy to avoid in C. I think I recognise your name from some rather aggressive rust advocacy in another thread, so I'll try and break this down in a way that won't trigger you: - Buffer overflows are trivial to avoid in Rust, AFAIK. I acknowledge this - Buffer overflows are very easy to code in C, and have occurred many times in the wild. Again, I acknowledge this. - My argument is - buffer overflows are easily preventable in C if you provide your own thin abstractions. The fact that people don't take these steps doesn't mean that these steps cannot be taken. Take the rust compiler itself: AFAIK it's now implemented in C++, an 'unsafe' language, and YET it manages to provide in abstraction in the form of a language that makes buffer overflows all but impossible. Do you understand now how it's possible create a safe abstractions in an unsafe language?
      - cwyers 10y ago
        > Do you understand now how it's possible create a safe abstractions in an unsafe language? Who cares? What's "possible" is completely besides the point. What matters what is done. And so, yes, you can create safe abstractions in C. But if you need to interoperate with someone else's C code, you have to deal with how your abstractions interact with someone else's, or someone else's lack of them. The point of using a language like Rust or Go or... pretty much any non-C language with lots of traction is that you don't have to provide "your own thin abstractions." You use the same one as everyone else. The point of Rust or Go isn't to make things easier on you. It's to protect you from every other piece of code you interact with. The standard library. Libraries written in the language. Other people working on the same project as you. Yourself five weeks ago. You all use the SAME safe abstraction. Nobody has to roll their own. There aren't 25 safe abstractions for 20 people working on the project. You don't have to reason out or guess whether or not some library (or even the standard library) is doing the right thing to avoid buffer overrun. You don't need to defend your entire codebase against someone else's code not doing the right thing.
  - simondedalus 10y ago
    obviously decades of security advisories means it's not easy. what in the world does 'easy' mean in your current usage? surely "tons of failures" is a better indicator of difficulty than "it feels easy to me / that's 'naturally how my brain works'," etc. and of course, if lots of people fail at something, it will get proportionally harder with a larger team / larger codebase / different stakeholders demanding xyz, etc etc etc. not chiming in about the basic disagreements in this thread, but the repeated claim that something that has caused trouble for countless professionals is "easy" just can't be right. if all the qualified people are "unqualified" because they all fail at something "everyone can do," the speaker is the one who's confused, and it's a lexical problem.
    - lacampbell 10y ago
      I never said everyone could do it. But a competent C programmer definitely can. I suppose I am an elitist in the sense that I don't think novice or careless programmers should be writing production code. I mean people manage to do a lot of dangerous things due to sloppiness - cause car accidents, for example. I don't think it's hard to avoid that, and I don't think those people should be driving. I suppose others think we need wider roads and bumper cars.

civility 10y ago

I'll bet he can give you an array_read() function that does what you ask. I know I could.

deleted 10y ago
[deleted]
lacampbell 10y ago
The fact that it doesn't occur to people to build safe abstractions in C to deal with things like buffer overflows still shocks me. C is fairly low level by todays standards. You 100% have to build abstractions using the standard library and then use those abstractions, rather than just using standard library functions everywhere. This isn't an argument against safer languages, or higher level languages, or languages with built in bounds checking or anything else. This is more an argument against programming in a "close to the metal" language like C so thoughtlessly that buffer overflows are actually a serious issue. Maybe you just need a pedantic mind. When first learning C, as soon as I figured out that writing "char buffer[BUFFER_LEN];" could cause your program to crash, I immediately set out to write a safe dynamic array implementation I could push chars onto it and I didn't have to worry. And I am by no means an expert C programmer.
- munin 10y ago
  Is this abstraction zero-cost? What's the overhead? Can you give me a similar set of primitives to manipulate memory in a temporally safe manner as well? What is the cost of that abstraction? How does it compare to a runtime's GC?
  - civility 10y ago
    > Is this abstraction zero-cost? What's the overhead? It will cost a single correctly predicted branch, which is effectively free on modern architectures. Any "safe" language will have to make this conditional branch too (Rust's File::read method will check the size of the slice).
    - 10y ago

imtringued 10y ago

Sure, if the array index is limited to 32 or 16 or 8 bits I can also give it to you at no performance cost for heap allocated arrays (i.e. no bound check happen at runtime). There is some memory overhead per array with this method though.