3 ms·

Why would you want to zero a buffer ? Because it may contain sensitive information, I presume. If you don't have additional properties w.r.t allocated memory, w

• nitrogen 12y ago
  what prevent a system with high load to temporarily put the given memory block on swap mlock() or mlockall() is useful in this case, but those are POSIX functions, not C.
• bostik 12y ago
  There is mlock(2), which is supposed to prevent the memory from being swapped. The problem with that is that the call requires either root or CAP_IPC_LOCK. If your user lacks the capability, you have to run the program setuid root. Allocate the sensitive buffers at the start, call mlock() on them and only then drop the privileges. There's also the 10kg fine-tuning hammer, mlockall(2). That makes ALL the memory for the calling process to become unswappable. As it can lock either the "currently held" memory, or "all the memory to be allocated during process lifetime", it can provide for some additional amusement under memory pressure.
  • leni536 12y ago
    I assume this privilege problem can be solved now with UID namespaces in linux. However it's really ugly, depends on running multiple child processes and linux specific.
• ibisum 12y ago
  >Why would you want to zero a buffer ? Because it may contain sensitive information, I presume. You don't zero sensitive buffers. You randomize them, then free() them.
  • clarry 12y ago
    Why do you randomize them?
    • syncsynchalt 12y ago
      Because just free()ing them means anyone calling malloc() can get your password.
      • clarry 12y ago
        So why don't you zero them?
        • ibisum 12y ago
          Because then your attacker knows that your buffer had something in it of value.
  • ygra 12y ago
    A dead store is a dead store. It doesn't matter whether you write something random into it or zero. If the compiler notices that you cannot read it again anyway, it will elide the write.
• clarry 12y ago
  Nothing's perfect, but we do what we can. Swap encryption is cool.