On 7/27/17 10:20 AM, Moritz Maxeiner wrote:
On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer wrote:
On 7/27/17 9:24 AM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote:
I think we can correctly assume no fclose implementations exist that
do anything but access data pointed at by stream. Which means a
segfault on every platform we support.
On platforms that may not segfault, you'd be on your own.
In other words, I think we can assume for any C functions that are
passed pointers that dereference those pointers, passing null is
safely going to segfault.
Likewise, because D depends on hardware flagging of dereferencing
null as a segfault, any platforms that *don't* have that for C also
won't have it for D. And then @safe doesn't even work in D code either.
As we have good support for different prototypes for different
platforms, we could potentially unmark those as @trusted in those
cases.
--- null.d ---
version (linux):
import core.stdc.stdio : FILE;
import core.sys.linux.sys.mman;
extern (C) @safe int fgetc(FILE* stream);
void mmapNull()
{
void* mmapNull = mmap(null, 4096, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED | MAP_POPULATE, -1, 0);
assert (mmapNull == null, "Do `echo 0 >
/proc/sys/vm/mmap_min_addr` as root");
*(cast (char*) null) = 'D';
}
void nullDeref() @safe
{
fgetc(null);
}
void main(string[] args)
{
mmapNull();
nullDeref();
}
---
For some fun on Linux, try out
# echo 0 > /proc/sys/vm/mmap_min_addr
$ rdmd null.d
Consider `mmapNull` being run in some third party shared lib you
don't control.
Again, all these hacks are just messing with the assumptions D is making.
Which aren't in the official D spec (or at the very least I can't seem
to find them there).
You are right. I have asked Walter to add such an update. I should pull
that out to its own thread, will do.
You don't need C functions to trigger such problems.
Sure, but it was relevant to the previous discussion.
Right, but what I'm saying is that it's a different argument. We could
say "you can't mark fgetc @safe", and still have this situation occur.
I'm fine with saying libraries or platforms that do not segfault when
accessing zero page are incompatible with @safe code.
So we can't have @safe in shared libraries on Linux? Because there's no
way for the shared lib author to know what programs using it are going
to do.
You can't guarantee @safe on such processes or systems. It has to be
assumed by the compiler that your provided code doesn't happen.
It's not that we can't have @safe because of what someone might do, it's
that @safe guarantees can only work if you don't do such things.
It is nice to be aware of these possibilities, since they could be an
effective attack on D @safe code.
And it's on you not to do this, the compiler will assume the segfault
will occur.
It's not a promise the author of the D code can (always) make.
In any case, the @trusted and @safe spec need to be explicit about the
assumptions made.
I agree. The promise only works as well as the environment. @safe is not
actually safe if it's based on incorrect assumptions.
-Steve
