On 11/13/19 4:24 PM, Matthew Malcomson wrote:
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
Hi.
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.
Thanks for explanation, it works for me.
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?
Libsanitizer is capable of using colors for report printing.
I can help with that and come up with a patch for upstream.
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.
Question here would be if we should use non-zero tags here? Maybe related
to my comment about skipping of HWASAN_STACK_BACKGROUND 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.
Now I've got it here. Dot means that top-byte of a pointer equals to zero.
Right?
d) I agree, an address offset annotation on each line of the shadow
memory sounds useful.
I can come up with an upstream patch as well.
Thank you,
Martin
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.
