[PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[John McCall via cfe-commits]

On Mon, May 1, 2017 at 7:06 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> On Mon, May 1, 2017 at 3:58 PM, John McCall <rjmccall at gmail.com> wrote:
>
>> On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin <dberlin at dberlin.org>
>> wrote:
>>
>>> On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin <dberlin at dberlin.org>
>>> wrote:
>>>
>>>> On Mon, May 1, 2017 at 2:07 PM, John McCall <rjmccall at gmail.com> wrote:
>>>>
>>>>> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin <dberlin at dberlin.org>
>>>>> wrote:
>>>>>
>>>>>> So you believe that you can index into an object randomly by pointer
>>>>>>>> arithmetic and pull out a different field?
>>>>>>>>
>>>>>>>
>>>>>>> For starters, this is  illegal because you don't know where the
>>>>>>> padding bytes are.
>>>>>>> You cannot assume that X.a + 1 == X.b
>>>>>>> "Implementation alignment requirements might cause two adjacent
>>>>>>> members not to be allocated immediately after each other;"
>>>>>>>
>>>>>>> See 9.2.14
>>>>>>>
>>>>>>
>>>>>> IE at best you'd have to add
>>>>>>
>>>>>>  &(struct X*(0))->b - &(struct X*(0))->a
>>>>>>
>>>>>>
>>>>>> I don't believe this is legal either.
>>>>>>
>>>>>> Let me try to dredge up the long discussions we had about these cases
>>>>>> on the gcc mailing lists.
>>>>>> The conclusion was, i believe:
>>>>>>
>>>>>> "if you want to go marching through an object as a char *, that's
>>>>>> fine, if you expect to be able to get at fields by playing pointer
>>>>>> arithmetic games, from other fields, that is not)
>>>>>> I feel like every couple years, a different compiler has the same
>>>>>> aliasing discussions :)
>>>>>>
>>>>>
>>>>> With the caveat that, in practice, compilers have to support both:
>>>>>   a) "going up a level" by subtracting an offsetof, which is clearly
>>>>> officially intended and not otherwise supported,
>>>>>
>>>>
>>>> AFAIK, Vtable accesses were supported by doing this, but pretty much
>>>> nothing else.
>>>>
>>>
>>> and to be clear, i mean given:
>>>
>>> struct a
>>> {
>>> int a;
>>>  struct b bstruct;
>>> };
>>>
>>> given a pointer to bstruct, subtracting sizeof(int)  is not going to
>>> give you a pointer to a struct a.
>>>
>>
>> If sizeof(int) happens to equal offsetof(struct a, bstruct), it sure
>> should (if you're doing the pointer arithmetic on an appropriate type, of
>> course).
>>
>>
>
>
>
>> It was allowed to work for vtable accesses.
>>>
>>
>> I would like to once again remind you that random mailing list
>> conversations you happened to be in but can't even remember from some
>> completely unnamed
>>
>
> It's not unnamed, it's either gcc@, gcc-patches@ or gcc bugzilla.
> I can even give you approximate dates if you like.
>
> I don't believe calling "the other major compiler's mailing list", which
> treaded exactly this topic, is "a random mailing list conversation", or "an
> unnamed source" or a "different context"
>

>
>> and possibly different context are neither authoritative nor binding on
>> us now. :)
>>
>> John, while i appreciate the smiley, this is kind of rude.
> Without a good reason to be different, we should follow the paths other
> compilers have taken and users have become used to. Both in what we allow,
> and what we disallow.
> So if the plan here is go off and do something that is going to be
> completely different than what users expect from their compilers, that
> doesn't make a lot of sense to me.
> Otherwise, if you really don't want me to tell you what they've done, and
> try to explain why, okay, fine, then i'll bow out of these discussion and
> leave y'all to do whatever.
>
> Just don't expect me to okay patches to llvm that implement the current
> kind of hacks we currently have.
>

Daniel, I have a huge amount of respect for the GCC developers and the work
that they've done, and I'm very interested in hearing what they thought.
If you're willing to present their discussions as prior art and as input
that we should consider in determining Clang's optimization strategy, I
think that would be extremely valuable.  But no, it is not appropriate to
treat those conversations as a sort of binding precedent that can only be
over-ruled with great force; it is completely reasonable for us to discuss
these things and come to different conclusions about both the meaning of
the standard and the proper design of an optimizer.

In particular, GCC has a history — of which this is an instance — of coming
up with a remarkably strict reading of the standard and then telling
anybody who complains to pass a flag to just disable the optimization.  To
my mind, that is not a reasonable way to design an optimizer, especially
when, frankly, that original reading seems pretty questionable and it seems
plausible that a weaker interpretation would still provide almost all of
the real optimization value.

In this case, it seems to me that the vast majority of the power of a
language rule that says that you cannot alias one field from a pointer to
another comes from forbidding out-of-bounds member array accesses from
reaching into earlier or later fields.  Such accesses will overwhelmingly
arise from member access expressions, not explicit pointer arithmetic on
char*; meanwhile, there are known idioms for pointer arithmetic on char*
that do not have any apparent replacement under a stronger rule.  In
situations like this, I think the burden lies on the designer of the
optimization to prove that it's both worth taking away a feature and that
there's no effective alternative.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170501/a4240a8e/attachment-0001.html>