[PATCH] D116769: [ifs] Allow llvm-ifs to generate text stub from elf stub
Roland McGrath via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 11 15:12:07 PST 2022
mcgrathr added inline comments.
================
Comment at: llvm/lib/InterfaceStub/ELFObjHandler.cpp:382
+ return StringRef(reinterpret_cast<const char *>(*DataOrErr),
+ DynEnt.StrSize);
+ }
----------------
haowei wrote:
> mcgrathr wrote:
> > Is there anything that validates that this size is within the bounds of the memory returned by toMappedAddr?
> There is no validating in this implementation and I think that is an issue. It would need a rewrite or reimplement of toMappedAddr to validate if the size is within the bounds of the same PT_LOAD segment returned by toMappedAddr. But if we just want validate if the size is still within all PT_LOAD, we can probably do:
>
> ```
> Expected<const uint8_t *> SecPtr = ElfFile.toMappedAddr(EntAddr);
> Expected<const uint8_t *> SecEndPtr = ElfFile.toMappedAddr(EntAddr + DynEnt.StrSize);
> ```
> And check if SecPtr and SecEndPtr contains any errors. Does that looks OK to you?
That would be better than nothing, but still susceptible to integer overflow. If there is nothing more robust than this that is easy to do without further refactoring, this seems like a wise incremental improvement. I think the long-term solution will indeed be to change this API to return some span-like type rather than a pointer so that accesses relative to the base address can be verified safe.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D116769/new/
https://reviews.llvm.org/D116769
More information about the llvm-commits
mailing list