[DTrace-devel] [PATCH v3 13/19] alloca: support null pointers

[Nick Alcock]

On 28 Mar 2022, Nick Alcock stated:

> On 28 Mar 2022, Kris Van Hees stated:
>>> +	emit(dlp,  BPF_BRANCH_IMM(BPF_JEQ, reg, 0, lbl_null));
>>> +	emit(dlp,  BPF_BRANCH_IMM(BPF_JSGT, reg, opt_scratchsize,
>>> +				  lbl_notnull));
>>> +	emit(dlp,  BPF_BRANCH_IMM(BPF_JSLT, reg, -opt_scratchsize,
>>> +				  lbl_notnull));
>>> +	dt_cg_probe_error(yypcb, lbl_null, DTRACEFLT_BADADDR, 0);
>>
>> This is a problem because we're doing this for every not-NULL check, even
>> if alloca is not involved.
>
> As noted above, I consider this a QoI matter, since every other null
> pointer check in every implementation out there will correct diagnose
> (by crashing) pointers *near* null, as well as pointers *at* null. The
> verifer is happy because we have a null check too.

Hm. Of course, underflows are much less common than overflows -- you can
only really get them by negative-array-indexing a null pointer.  I'd be
quite amenable to making these null checks a half-open range, which
would drop the BPF_JSLT and make the overhead only one instruction,
while retaining the ability to diagnose ((struct foo *)NULL)->bar,
which is the really problematical case, and ordinary array derefs of
null pointers too.

-- 
NULL && (void)