3 ms·

Unitialized bytes can NOT be considered "ordinary bytes" on x86. This is because of memory paging and copy-on-write. If a memory is untouched, it is allowed to

Unitialized bytes can NOT be considered "ordinary bytes" on x86. This is because of memory paging and copy-on-write. If a memory is untouched, it is allowed to map to a different physical memory on different accesses, so the contents are not only "unknown", they may change under your feet! You must touch the memory page for this not to happen.

iforgotpassword 8y ago
TIL, nice detail (Not that I would've recommended using uninitialized bytes as an RNG anyways ;))
gmueckl 8y ago
This cannot possibly be correct. A read access to a region without a mapped page in the page table will cause the CPU to trigger a page fault exception. The OS must then decide whether to map memory there a one time operation or abort the program. A second read from the same page must lead to the same mapping then. There is no sane way for an operating system to switch out program heap pages after they have been mapped.
- _pmf_ 8y ago
  > There is no sane way for an operating system to switch out program heap pages after they have been mapped. They'll even move the page to the harddisk if necessary. Or am I misunderstanding what you're asking?
  - gmueckl 8y ago
    The OS can move the content of the pages in physical memory, but it will not make the page table entry point to a page with different content after that point.
- vardump 8y ago
  I read "memory is untouched" as no read/write accesses. Because it'd be pretty odd for the page to change after first read from operating system implementation point of view. Generally I'd expect the default mapping to be to an all-zero physical memory page. (Unless there's a rowhammer attack (or similar) that successfully modifies said all-zero page...) From C/C++ point of view, it's legal for uninitialized memory to arbitrarily change between (undefined behavior) reads until it is written to. While I doubt any actual OS would modify the page in this manner after first read access, a C/C++ compiler can still return arbitrary (even random) values when reading from uninitialized memory. It doesn't even need to actually read from the memory proven to be uninitialized.
  - gpderetta 8y ago
    madvise MADV_DONTNEED
- ralfjung 8y ago
  This is looking at the wrong level of abstraction though. The compiler will already optimize your code in a way that multiple uses of the same uninitialized value can produce different results. Arguing about these assembly/CPU-level details (unfortunately?) is besides the point when debating the semantics of languages like C, C++ or Rust.
  - gmueckl 8y ago
    Grandparent already narrowed discussion down to x86 behaviour and I responded to details on that. This is definitely all outside the scope of language specifications.
- GolDDranks 8y ago
  I'm not going to take the responsibility whether it's correct or not - here's the talk I learned it from: https://youtu.be/kPR8h4-qZdk?t=22m17s https://youtu.be/kPR8h4-qZdk?t=22m17s
  - gmueckl 8y ago
    I haven't watched all of it, but the explanation for the null terminator bug must contain some OS interaction telling the kernel that it is actually safe to discard the page containing the null terminator (e.g. the madvice call mentioned in a sibling post). If you're doing things like that, you're asking for trouble.

iforgotpassword 8y ago

TIL, nice detail (Not that I would've recommended using uninitialized bytes as an RNG anyways ;))

gmueckl 8y ago

This cannot possibly be correct. A read access to a region without a mapped page in the page table will cause the CPU to trigger a page fault exception. The OS must then decide whether to map memory there a one time operation or abort the program. A second read from the same page must lead to the same mapping then. There is no sane way for an operating system to switch out program heap pages after they have been mapped.

_pmf_ 8y ago
> There is no sane way for an operating system to switch out program heap pages after they have been mapped. They'll even move the page to the harddisk if necessary. Or am I misunderstanding what you're asking?
- gmueckl 8y ago
  The OS can move the content of the pages in physical memory, but it will not make the page table entry point to a page with different content after that point.
vardump 8y ago
I read "memory is untouched" as no read/write accesses. Because it'd be pretty odd for the page to change after first read from operating system implementation point of view. Generally I'd expect the default mapping to be to an all-zero physical memory page. (Unless there's a rowhammer attack (or similar) that successfully modifies said all-zero page...) From C/C++ point of view, it's legal for uninitialized memory to arbitrarily change between (undefined behavior) reads until it is written to. While I doubt any actual OS would modify the page in this manner after first read access, a C/C++ compiler can still return arbitrary (even random) values when reading from uninitialized memory. It doesn't even need to actually read from the memory proven to be uninitialized.
- gpderetta 8y ago
  madvise MADV_DONTNEED
ralfjung 8y ago
This is looking at the wrong level of abstraction though. The compiler will already optimize your code in a way that multiple uses of the same uninitialized value can produce different results. Arguing about these assembly/CPU-level details (unfortunately?) is besides the point when debating the semantics of languages like C, C++ or Rust.
- gmueckl 8y ago
  Grandparent already narrowed discussion down to x86 behaviour and I responded to details on that. This is definitely all outside the scope of language specifications.
GolDDranks 8y ago
I'm not going to take the responsibility whether it's correct or not - here's the talk I learned it from: https://youtu.be/kPR8h4-qZdk?t=22m17s https://youtu.be/kPR8h4-qZdk?t=22m17s
- gmueckl 8y ago
  I haven't watched all of it, but the explanation for the null terminator bug must contain some OS interaction telling the kernel that it is actually safe to discard the page containing the null terminator (e.g. the madvice call mentioned in a sibling post). If you're doing things like that, you're asking for trouble.