Re: [Xen-devel] [PATCH for-4.10 1/2] ubsan: add clang 5.0 support

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.10.17 at 14:57, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, Oct 17, 2017 at 06:43:28AM -0600, Jan Beulich wrote:
>> >>> On 17.10.17 at 13:36, <roger.pau@xxxxxxxxxx> wrote:
>> > clang 5.0 changed the layout of the type_mismatch_data structure and
>> > introduced __ubsan_handle_type_mismatch_v1 and
>> > __ubsan_handle_pointer_overflow.
>> > 
>> > This commit adds support for the new structure layout, adds the
>> > missing handlers and the new types for type_check_kinds.
>> > 
>> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> 
>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
>> with a remark:
>> 
>> > +void __ubsan_handle_pointer_overflow(struct pointer_overflow_data *data,
>> > +                          unsigned long base, unsigned long result)
>> > +{
>> > +  unsigned long flags;
>> > +
>> > +  if (suppress_report(&data->location))
>> > +          return;
>> > +
>> > +  ubsan_prologue(&data->location, &flags);
>> > +
>> > +  pr_err("pointer overflow:\n");
>> > +
>> > +  if (((long)base >= 0) == ((long)result >= 0))
>> > +          pr_err("%s of unsigned offset to %p overflowed to %p\n",
>> > +                  base > result ? "addition" : "subtraction",
>> 
>> Strictly speaking you also want to make "to" conditional upon this
>> being an add; for subtract it ought to be "from". Or perhaps just
>> say overflow and underflow?
>> 
>> And then - is "base > result" really a valid determination of
>> add/subtract (or overflow/underflow)? If the pointed to type is
>> wider than one byte, an addition may wrap one or more times
>> and still yield a value larger than the starting pointer.
> 
> That code is mostly adapted from upstream llvm:
> 
> https://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/ubsan/ubsan_handler
>  
> s.cc?revision=313572&view=markup
> 
> But I see your point, if the types have different widths that check
> won't work properly. In any case, I don't see a better way to deal
> with this.

Well, as said - perhaps simply use

        pr_err("pointer operation %s %p to %p\n",
               base > result ? "underflowed" : "overflowed",

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel