Emplace vs closures

[cym13 via Digitalmars-d]

On Thursday, 22 September 2016 at 12:08:19 UTC, Steven 
Schveighoffer wrote:
> 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.

We lose at least all linux kernels before 2.6.23... although it 
sounds reasonnable it's a choice that's better made knowingly ;)

>> 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

This is very interesting, I'm sure there are ways to expand on 
this idea further (but even just that would be a real 
improvement). One thing is that although I don't see people 
willingly creating such a big struct not all D code is written by 
humans and with some mixin or template help it's a possibility. 
I'd love to see some protection where the compiler can work it 
out.