[Issue 16526] New: @safe code should do null check for members when appropriate

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16526

          Issue ID: 16526
           Summary: @safe code should do null check for members when
                    appropriate
           Product: D
           Version: D2
          Hardware: x86
                OS: Mac OS X
            Status: NEW
          Keywords: safe
          Severity: enhancement
          Priority: P1
         Component: dmd
          Assignee: nobody at puremagic.com
          Reporter: schveiguy at yahoo.com

If I have a struct like this:

struct S
{
  int[10_000] data
}

I can access memory I'm not supposed to, even in @safe code, that is beyond the
zero page:

void main() @safe
{
   S * ptr;
   ptr.data[9999] = 5;
}

This data could be unmapped or mapped (on my 64-bit system, it's not mapped, so
a segfault still occurs). But it is a possible way to have an exploit in @safe
code.

I propose that if the compiler can detect at compile-time that access to a
member of a struct is beyond the zero page if a pointer happens to point at
null, then it should check for a null pointer (actually, it should just
dereference the first word pointed at by the pointer, and trigger a segfault).
It only needs to do this once if it can determine the pointer or reference will
not change.

If the access to the member is determined at compile-time to point within one
page of the front of the struct pointer (either by knowing at compile time the
index being accessed, or knowing that the struct is less than one page in
size), then no instrumentation is needed.

If the access cannot be determined to be within one page at compile-time, then
the check should still be made during runtime.

If one takes a reference to a member that is outside the one-page limit, then
the same check can be performed. There are still ways to access data beyond one
page without incurring a check with this scheme, but we are talking about very
weird and rare code.

This scheme should leave most code intact, and in rare cases, add a few null
checks here and there. Note that by null check, you aren't actually checking
against null, but simply using the built-in ability to segfault. So it's cheap.

--