[DTrace-devel] [PATCH v3 09/19] alloca: deref

[Nick Alcock]

On 31 Mar 2022, Kris Van Hees spake thusly:

> Still going through this patch in further detail but here are some first
> comments:
>
> 1. It seems that several tests in this patch are not related to alloca
>    ptr deref at all.  They should be moved to the patch(es) that provide
>    the implementation code that is being tested.

None of them work without the code in deref, AIUI, with a couple of
exceptions which are close relatives of tests that *do* need deref.

> 2. The following test is added as a test that is expected to report a fault:
>
> 	unittest/funcs/alloca/err.alloca-store-load-aliasing-arith-bottom.d	
>
>    However, this test does not report a fault on DTrace on Solaris.  It does
>    work there:
>
> dtrace -n 'BEGIN { s = (char *)alloca(10); j = s - 1; j[1] = 65; trace(s[0]); exit(0); }'
> dtrace: description 'BEGIN ' matched 1 probe
>  CPU     ID                    FUNCTION:NAME
>    0      1                           :BEGIN   65
>
>    I would expect it to work for DTrace based on BPF as well.  After all, there
>    is no deref of j until we handle j[1] which is *(j + 1) and that is a valid
>    pointer.
>
> Again, this is just first observation.  But points out a problem in terms of
> equivalent behaviour with the reference implementation for DTrace.

Hmm I'd not expect that to fault either :) ...

... ah yes, this is testing another invariant: we bounds-check pointers
at the time they are extracted from the variable, so we can transform
them into map_value pointers relative to the alloca base and compute
their bounds properly. Alas... if they already point outside the
map_value region, the verifier will reject them.

If we don't bounds-check that early, alloca pointers stay as scalars
until deref time (and all hell breaks loose because no other pointers do
that, including pointers acquired direclty from alloca(): in general we
want things that are pointers to have the same representation no matter
where they came from, or we'll have to make all the cg work for both
pointers and scalars depending on where they came from originally, which
seems likely to be just horrible and require a lot of extra code to
scalarize and descalarize things all over the place). If we do
bounds-check that early, the verifier insists the pointer is within the
bounds.

I see no way around this without the crazy overdesign of carting around
both a base and an offset with every pointer just to allow us to do
things like this (zero base, negative offset). Added a comment to the
test, anyway.