4 ms·

I don't get it, the compiler operates within the memory model specified by the language. If it "optimizes" a memset it does not change the behavior of the progr

by Joky 11y ago

I don't get it, the compiler operates within the memory model specified by the language. If it "optimizes" a memset it does not change the behavior of the program (or it is a bug in the compiler which is a different topic).

TheLoneWolfling 11y ago
You're correct - the compiler operates within the memory model of the language. But C / C++'s memory model is broken w.r.t. security. There is no way to ensure that something is actually overwritten, because under the memory models of C and C++ you cannot ever read that memory again, even though in actuality you can.
- ikeboy 11y ago
  Why not generate random data then read it? Or even a constant, then read it?
  - TheLoneWolfling 11y ago
    Because the compiler will optimize it out. Even if you return the random data / constant the compiler will optimize out the store to the variable and just pass it through directly.
- Joky 11y ago
  I believe volatile force the compiler to issue a real write to memory and can't be optimized away.
  - TheLoneWolfling 11y ago
    Except, of course, that the compiler can perfectly legally copy the variable behind the scenes and not overwrite the copy. I mean it when I say you cannot.
    - Joky 11y ago
      I'm not sure what you mean here, if you have a volatile pointer that points to a memory buffer returned by malloc, how can the compiler prevents a write through the pointer from happening? Edit: unless your point is a temporary copy can be spilled in memory and this copy will stay in memory and won't be overwritten?
      - TheLoneWolfling 11y ago
        Yes, your edit is correct.
ori_b 11y ago
The problem is that the memory model specified by the language is a subset of the memory model specified by the hardware. This leads to exploitable systems when you lift those blinders.
Too 11y ago
Common misconception with C. A pointer does not mean a pointer to a sequence of capacitors in your RAM-memory. It really means a pointer to an abstract and temporary variable. How this abstract variable is executed on your hardware is implementation specific. Everything except input, output and explicitly defined side effects (volatile) is of no interest. Really, you can print a c program on piece of paper and ask some slave to "execute" the program in his head given some input x, how he "implements" memset will surely be different than what a computer would, and if you only ask for the output y he will surely see that this memset doesn't affect y at all and skip doing it.

by Joky 11y ago

TheLoneWolfling 11y ago

You're correct - the compiler operates within the memory model of the language. But C / C++'s memory model is broken w.r.t. security. There is no way to ensure that something is actually overwritten, because under the memory models of C and C++ you cannot ever read that memory again, even though in actuality you can.

ikeboy 11y ago
Why not generate random data then read it? Or even a constant, then read it?
- TheLoneWolfling 11y ago
  Because the compiler will optimize it out. Even if you return the random data / constant the compiler will optimize out the store to the variable and just pass it through directly.
Joky 11y ago
I believe volatile force the compiler to issue a real write to memory and can't be optimized away.
- TheLoneWolfling 11y ago
  Except, of course, that the compiler can perfectly legally copy the variable behind the scenes and not overwrite the copy. I mean it when I say you cannot.
  - Joky 11y ago
    I'm not sure what you mean here, if you have a volatile pointer that points to a memory buffer returned by malloc, how can the compiler prevents a write through the pointer from happening? Edit: unless your point is a temporary copy can be spilled in memory and this copy will stay in memory and won't be overwritten?
    - TheLoneWolfling 11y ago
      Yes, your edit is correct.

ori_b 11y ago

The problem is that the memory model specified by the language is a subset of the memory model specified by the hardware. This leads to exploitable systems when you lift those blinders.

Too 11y ago

Common misconception with C. A pointer does not mean a pointer to a sequence of capacitors in your RAM-memory. It really means a pointer to an abstract and temporary variable. How this abstract variable is executed on your hardware is implementation specific. Everything except input, output and explicitly defined side effects (volatile) is of no interest. Really, you can print a c program on piece of paper and ask some slave to "execute" the program in his head given some input x, how he "implements" memset will surely be different than what a computer would, and if you only ask for the output y he will surely see that this memset doesn't affect y at all and skip doing it.