On 9/20/16 12:45 PM, cym13 wrote:
On Tuesday, 20 September 2016 at 14:00:00 UTC, Steven Schveighoffer wrote:
Dereferencing a null pointer is perfectly safe in user space (where
you can't map the zero page). Indexing a null pointer is not. In this
case, we are indexing a null pointer, so there is the potential for
abuse, but very very small.
Note that not all operating systems disallow mapping the zero page
(although they admitedly should). And yes the potential for abuse is
small, I've just getting annoyed at dangerous generalities.
We can simply avoid supporting such OSes, I don't think we lose much!
But thanks for pointing this out, I didn't know that.
In that specific case I don't think it should be treated as a security
issue in the general case although it could become one if used in an
unfavorable environment.
I had an interesting thought, and this is actually a @safe issue (I'll
file an issue request). If you have a potentially large enough struct,
then accessing items in that struct has the potential to go beyond the
unmapped memory.
However, in MOST cases, the compiler knows the offset being used
(especially if accessing specific members). In some cases it doesn't.
But one thing the compiler can do (at least in @safe code) is:
1. If the index is known at compile time to go beyond one page (or
beyond the known OS limit for unmapped pages), do a null pointer check
first, and abort with segfault if possible. As simple as loading the
byte/word at the front of the struct. You also only have to do this once
if the struct pointer does not move.
2. If the index is not known until runtime (for instance, indexing a
static array in a struct), then check for null pointer before
dereferencing conservatively.
This would make code that is very common (i.e. small struct size, or
accessing front members of the struct) just use the hardware features to
prevent access. Code that is rare (accessing members beyond one page of
size) can be instrumented to ensure no exploits are possible.
-Steve
