This is an archive of the discontinued LLVM Phabricator instance.

[JITLink] Add fixup value range check
ClosedPublic

Authored by StephenFan on Aug 3 2021, 12:54 AM.

Details

Summary

This patch makes jitlink to report an out of range error when the fixup value out of range

Diff Detail

Event Timeline

StephenFan created this revision.Aug 3 2021, 12:54 AM
StephenFan requested review of this revision.Aug 3 2021, 12:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2021, 12:54 AM
lhames accepted this revision.Aug 14 2021, 6:34 PM

LGTM. Thanks Stephen!

This revision is now accepted and ready to land.Aug 14 2021, 6:34 PM
This revision was automatically updated to reflect the committed changes.
jrtc27 added a comment.Jan 4 2022, 7:41 AM

This was clearly not done whilst referencing LLD's implementation as it's buggy. Please fix.

llvm/lib/ExecutionEngine/JITLink/ELF_riscv.cpp
199–201

You need to check that Value + 0x800 is a 32-bit signed integer, not that Value is a 32-bit unsigned integer. LUI sign-extends, hence checking it as a signed integer, and the + 0x800 needs to be added to account for the slight asymmetry resulting from the ADDI/etc's sign-extension of the LO12.

212

LO12 should never be range checked, it's a waste of time as the HI20 half will also range check.

233

As with HI20, this needs to check Value + 0x800, not Value. But this at least already checks it as a signed integer rather than an unsigned integer.

251

As with LO12, these are a waste of time

lhames added inline comments.Jan 4 2022, 4:20 PM
llvm/lib/ExecutionEngine/JITLink/ELF_riscv.cpp
212

If LO12/HI20 relocations are always paired then it seems reasonable to elide the range check here, but we'd need a check that both elements of the pair are present in the input object: JITLink's policy is to assume that objects may be malformed / maliciously crafted and always check.

That needn't be addressed straight away, but we should at least add a FIXME for it.

StephenFan reopened this revision.Jan 9 2022, 5:04 PM
This revision is now accepted and ready to land.Jan 9 2022, 5:04 PM

Address @jrtc27's comments

StephenFan marked 5 inline comments as done.Jan 9 2022, 10:11 PM
lhames accepted this revision.Jan 9 2022, 11:58 PM

The code should be clang-formatted. Otherwise LGTM.

Clang-format and delete unused function

clang-format

This revision was landed with ongoing or failed builds.Jan 13 2022, 12:33 AM
This revision was automatically updated to reflect the committed changes.