Emplace vs closures

[cym13 via Digitalmars-d]

On Tuesday, 20 September 2016 at 14:00:00 UTC, Steven 
Schveighoffer wrote:
> On 9/20/16 4:08 AM, cym13 wrote:
>> On Monday, 19 September 2016 at 14:22:16 UTC, Steven 
>> Schveighoffer wrote:
>>>[...]
>>
>> I beg to defer, null pointer dereference is certainly not safe 
>> in the
>> general case. In many cases it lead to code execution or 
>> privilege
>> escalation. See for example CVE-2008-568 [1] for an example in 
>> kernel
>> space or CVE-2009-0385 [2] in user space.
>
> In kernel space, yes. So don't do this in your D kernel :)
>
> In user space, the chance is very unlikely. It requires a 
> function context to be larger than the reserved page space, and 
> accessing a function context variable outside that space.
>
> Not impossible, but very very unlikely. And beyond the control 
> of the exploiter.
>
>> The idea is that you are really trying to call a function in a 
>> part of
>> memory that is not mapped, but if you are able to map the zero 
>> page and
>> control what function pointer is present there then it is 
>> exploitable.
>> I'd like people to get away from the idea that null pointer 
>> dereference
>> is safe, it's not. In most cases it's not exploitable but 
>> that's
>> definitely not a safe spot.
>
> 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.

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'm still not sure that emplace on an inner struct is a thing 
> we need to allow, especially when it's known that the context 
> pointer will be invalid. Maybe we should only allow if called 
> via a different name, to prevent unwitting uses.
>
> -Steve