3

I've recently been pointed into one of my C programs that, should the start address of the memory block be low enough, one of my tests would fail as a consequence of wrapping around zero, resulting in a crash.

At first i thought "this is a nasty potential bug", but then, i wondered : can this case happen ? I've never seen that. To be fair, this program has already run millions of times on a myriad of systems, and it never happened so far.

Therefore, my question is : What is the lowest possible memory address that a call to malloc() may return ? To the best of my knowledge, i've never seen addresses such as 0x00000032 for example.

I'm only interested in "modern" environments, such as Linux, BSD and Windows. This code is not meant to run on a C64 nor whatever hobby/research OS.

Matt
  • 22,721
  • 17
  • 71
  • 112
Cyan
  • 13,248
  • 8
  • 43
  • 78

3 Answers3

8

First of all, since that's what you asked for, I'm only going to consider modern systems. That means they're using paged memory and have a faulting page at 0 to handle null pointer dereferences.

Now, the smallest page size I'm aware of on any real system is 4k (4096 bytes). That means you will never have valid addresses below 0x1000; anything lower would be part of the page containing the zero address, and thus would preclude having null pointer dereferences fault.

In the real world, good systems actually keep you from going that low; modern Linux even prevents applications from intentionally mapping pages below a configurable default (64k, I believe). The idea is that you want even moderately large offsets from a null pointer (e.g. p[n] where p happens to be a null pointer) to fault (and in the case of Linux, they want code in kernelspace to fault if it tries to access such addresses to avoid kernel null-pointer-dereference bugs which can lead to privilege elevation vulns).

With that said, it's undefined behavior to perform pointer arithmetic outside of the bounds of the array the pointer points into. Even if the address doesn't wrap, there are all sorts of things a compiler might do (either for hardening your code, or just for optimization) where the undefined behavior could cause your program to break. Good code should follow the rules of the language it's written in, i.e. not invoke undefined behavior, even if you expect the UB to be harmless.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Thanks, so apparently my code seems safe. I'm however interested in understanding what kind of "bad practice" should better be avoided. I understand that the pointer should not go outside of the array, otherwise it's undefined behavior, but what if the point of my test is to detect just that ? – Cyan Dec 08 '12 at 23:45
  • 1
    If you mean you're doing something like `if (ptr+n < begin || ptr+n >= end) ...`, then what you should instead be doing is (assuming `n` is signed and `ptr` is a valid pointer somewhere in the array) `if (n < begin-ptr || n >= end-ptr) ...`. In other words, rearrange your tests algebraically to ensure that overflow (for integers) or out-of-bound pointer arithmetic (for pointers) cannot happen. This is a very worthwhile skill to learn in general for safe programming, even if you don't strictly "need" it here. – R.. GitHub STOP HELPING ICE Dec 08 '12 at 23:54
  • Thank. This is an advise i should use in a lot of other parts of my code, even if they work fine today. – Cyan Dec 09 '12 at 00:02
  • Quick note : it seems that, unfortunately, the proposed way of testing pointer correctness is not as fast as simple pointer comparison. There is a noticeable drop in performance when implementing it. – Cyan Dec 09 '12 at 16:09
  • It would probably cost even less time to avoid having to make the comparison by making sure your code never gets out-of-bound indices to begin with... Short of that, I think you should take a look at the generated asm and figure out why it's slower. It might actually be indicative of a bug. There are lots of ways you could mess this comparison up with types of the wrong signedness, etc... – R.. GitHub STOP HELPING ICE Dec 09 '12 at 17:30
  • All pointers created and modified by my function are "trusted" (guarantee to never get out-of-bound). Unfortunately, i can't tell the same for pointers provided by outside sources. The tests are for them. – Cyan Dec 09 '12 at 20:18
  • Perhaps you could elaborate on your usage case; it's possible that the entire check is useless. In C you **always** have to trust that the caller of your function obeys its interface contract. – R.. GitHub STOP HELPING ICE Dec 09 '12 at 22:40
4

You probably mean that you are computing &a - 1 or something similar.

Please, do not do this, even if pointer comparison is currently implemented as unsigned comparison on most architectures, and you know that (uintptr_t)&a is larger than some arbitrary bound on current systems. Compilers will take advantage of undefined behavior for optimization. They do it now, and if they do not take advantage of it now, they will in the future, regardless of “guarantees” you might expect from the instruction set or platform.

See this well-told anecdote for more.

In a completely different register, you might think that signed overflow is undefined in C because it used to be that there were different hardware choices such as 1's complement and sign-magnitude. Therefore, if you knew that the platform was 2's complement, an expression such as (x+1) > x would detect MAX_INT.

This may be the historical reason, but the reasoning no longer holds. The expression (x+1) > x (with x of type int) is optimized to 1 by modern compilers, because signed overflow is undefined. Compiler authors do not care that the original reason for undefinedness used to be the variety of available architectures. And whatever undefined thing you are doing with pointers is next on their list. Your program will break tomorrow if you invoke undefined behavior, not because the architecture changed, but because compilers are more and more aggressive in their optimizations.

Pascal Cuoq
  • 79,187
  • 7
  • 161
  • 281
  • Thanks for detailed explanations. I'm comparing 2 pointers. One of them is "trusted" (created and modified by my function), the other one is not trusted, since it is the result of an operation with one argument provided by an "outside source". Both pointers are supposed to point into the same "valid" memory block, except if the "outside argument" is deliberately false (attack scenario, which the test attempts to detect). – Cyan Dec 08 '12 at 23:41
  • @Cyan I am painting a bleak picture in my answer for rhetorical reasons, but to my knowledge, comparing `(uintptr_t)trusted` and `(uintptr_t)outside` should be safe. The cast in those is implementation-defined, which limits compilers' ability to optimize. – Pascal Cuoq Dec 08 '12 at 23:44
2

Dynamic allocations are performed on heap. Heap resides in a process address space just after the text (the program code), initialized data and uninitialized data sections, see here: http://www.cprogramming.com/tutorial/virtual_memory_and_heaps.html . So the minimal possible address in the heap depends on the size of these 3 segments thus there is no absolute answer since it depends on the particular program.

SomeWittyUsername
  • 18,025
  • 3
  • 42
  • 85