This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj] - Do not crash when an invalid .eh_frame_hdr is dumped using --unwind.
ClosedPublic

Authored by grimar on May 21 2020, 7:39 AM.

Details

Summary

When the p_offset/p_filesz of the PT_GNU_EH_FRAME is invalid
(e.g larger than the file size) then llvm-readobj might crash.

This patch fixes the issue. I've introduced ELFFile<ELFT>::getSegmentContent
method, which is very similar to ELFFile<ELFT>::getSectionContentsAsArray one.

Diff Detail

Event Timeline

grimar created this revision.May 21 2020, 7:39 AM
Herald added a project: Restricted Project. · View Herald Transcript
grimar marked an inline comment as done.May 21 2020, 7:40 AM
grimar added inline comments.
llvm/tools/llvm-readobj/DwarfCFIEHPrinter.h
113

Note: we might want to change this and all other reportError calls in the PrinterContext<ELFT> to report warnings.

jhenderson added inline comments.May 26 2020, 1:21 AM
llvm/include/llvm/Object/ELF.h
72

Twine instead of std::to_string?

73

Delete "the".

llvm/test/tools/llvm-readobj/ELF/unwind.test
287

"so large a value that it overflows" is slightly more grammatically correct, I think (English is weird - most native speakers don't even have a good grasp of all the rules, but this feels right!).

I wonder if we should have a 64-bit version of this same case, since it has a different upper bound?

llvm/tools/llvm-readobj/DwarfCFIEHPrinter.h
113

Sounds reasonable to me, but probably a separate change.

grimar updated this revision to Diff 266182.May 26 2020, 5:59 AM
grimar marked 6 inline comments as done.
  • Addressed review comments.
llvm/test/tools/llvm-readobj/ELF/unwind.test
287

I wonder if we should have a 64-bit version of this same case, since it has a different upper bound?

Yes, probably.

It seems was not possible (or too complicated, I was unable to) to produce the right values for the program header with the previous approach (because of overflows happening), so I've also changed how tests are implemented. Now I set needed size/offset values directly for the PT_GNU_EH_FRAME. It is the most straightforward way to set them and I it also looks much cleaner than before I think. Not sure why I did not do it in this way from the begining.

I've also added a test (Case D) for "p_memsz does not match p_filesz for GNU_EH_FRAME" error (seems we do not have it anywhere, but it is related). I'd improve this message in a follow-up though to report actual values.

llvm/tools/llvm-readobj/DwarfCFIEHPrinter.h
113

Yes. That is what I meant, it is in my TODO list.

jhenderson added inline comments.May 27 2020, 1:37 AM
llvm/test/tools/llvm-readobj/ELF/unwind.test
305

so large -> is so large

327

Perhaps you should just keep Case D in a separate patch, and improve the error text at the same time. It's not really related to the rest of the changes you are making, I think. Anyway, why is this an error at all? I'm not convinced it's really anything to do with dumping. It might be some sort of validation error if we had something equivalent to llvm-dwarfdump --verify, but I'm not convinced it belongs in llvm-readelf as things stand.

grimar marked an inline comment as done.May 27 2020, 2:19 AM
grimar added inline comments.
llvm/test/tools/llvm-readobj/ELF/unwind.test
327

Anyway, why is this an error at all?

It was introduced in D43313.
I guess it was just a some kind of sanity check. Having Phdr.p_memsz != Phdr.p_filesz probably means something is wrong with the header (e.g a bss section was included?). Perhaps we should just convert it to warning and use p_filesz when trying to printEHFrameHdr().

I'll remove "case D" and investigate it separatelly.

grimar updated this revision to Diff 266484.May 27 2020, 4:13 AM
  • Removed "Case D".
  • Fixed comment.
This revision is now accepted and ready to land.May 27 2020, 4:22 AM
This revision was automatically updated to reflect the committed changes.