On 12/11/2019 12:08, Martin Liška wrote:
> On 11/11/19 5:03 PM, Matthew Malcomson wrote:
>> Ah!
>> My apologies -- I sent up a series with a few documentation mistakes.
>> (the others were wording problems so less noticeable)
>
> That's fine, I fixed that very easily.
>
> Right now, I can confirm using a aarch64 KVM with the following linux
> kernel:
> 5.4.0-rc6-3.g7068448-default works. I haven't tried HWASAN bootstrap,
> but I can
> run almost all hwasan.exp tests.
>
> There are 2 exceptions:
>
> FAIL: gcc.dg/hwasan/stack-tagging-basic-1.c -O2 -flto
> -fuse-linker-plugin -fno-fat-lto-objects execution test
> FAIL: gcc.dg/hwasan/large-aligned-1.c -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects execution test
Wow, I have no idea how I missed that but thanks for the catch!
>
> These fail due to unused value of a function that returns int. The
> attached patch fixes that.
> I'm planning to make a proper comments about the series starting next week.
>
> For the meantime, I have some libsanitizer upstream suggestions
> that you can may be discuss. It's mostly about
> shadow memory dump differences in between ASAN and HWASAN:
>
>
> Improvements I see:
> a) HWASAN uses less compact dump (2 spaces compared to one)
> b) HWASAN is not using colors and it would be handy to know which color
> is used for "uninitialized" tags
> and I would mark the 2 compares tags in dumps (ptr/mem)
> c) "Tags for short granules around the buggy address" dump is using a
> dot notation which seems a bit misleading
> d) For HWASAN address offset is missing for each line in both shadow
> memory and the pointer
To mention my thoughts in turn:
a) The dump of HWASAN takes more space, but represents more application
bytes for a given space on the console.
Each byte of HWASAN shadow space represents 16 application bytes
while each byte in ASAN shadow space represents 8 application bytes.
I personally appreciate the extra spacing, and figure that the 8|16
byte difference allows for this.
b) Marking 'ptr' and 'mem' in the dump sounds like a good idea to me.
Exactly how I'm not sure -- maybe with a colourscheme? Do you have a
marking in mind?
Uninitialised shadow space has the zero tag, however, there are a few
extra details that help understanding these traces:
On the stack, zero is both uninitialized and "the background" (i.e.
the tag for anything not specially instrumented, like register spills
and parameters passed on the stack).
However, accessible tagged objects can be given a zero tag.
We allow this to avoid runtime checks when incrementing the random
frame tag to get the tag for a new local variable.
We can easily avoid the zero tag at compile-time if we don't use a
random tag for each frame. I had this in development at one point
and found it quite useful for verification. I already have an option
to disable random tags for each frame that this ability could go
under.
I don't believe (but am not 100% certain) this option is in LLVM.
On the heap uninitialised is tag zero, but memory that has been
`free`d is given a random tag, so non-zero in a dump does not mean a
valid object.
c) Is there an alternate notation you have in mind?
I would guess the "dots" are there to say "this granule has no
short-tag information", and I'm not sure what would be a better
way to demonstrate that.
d) I agree, an address offset annotation on each line of the shadow
memory sounds useful.
Cheers,
MM
>
> Thanks,
> Martin
>
>>
>> I'm attaching the entire updated patch series (with the other
>> documentation fixes in it too) and the fixed patch for just this part in
>> case you just want to compile and test right now.
>
