[Sanitizers][Apple] Fix logic bugs that break RestrictMemoryToMaxAddress (#124712)

There are two logic bugs breaking RestrictMemoryToMaxAddress.
1. adding left_padding within MapDynamicShadow.
- RoundUpTo((uptr)free_begin + left_padding, alignment) already adjusts
for left padding. Adding this additionally within MapDynamicShadow
causes us to allocate a page larger than necessary.
- This incorrect calculation also means RestrictMemoryToMaxAddress will
never find a big enough gap.


2. There is also an issue with the expectation of hitting
KERN_INVALID_ADDRESS when we are beyond the addressable regions.
- For most embedded scenarios, we exceed vm_max_address without getting
KREN_INVALID_ADDRESS so we setting max_occupied_address to a memory
region the process doesn't have access to, beyond the max address, and
that space is never marked as available so we never find a valid gap in
those regions.
- At some point previous it seems the assumption was once we were beyond
the Max address we could expect KREN_INVALID_ADDRESS, which is no longer
true up through the extended space not given to most processes.
- Because of this, the check` if (new_max_vm < max_occupied_addr)` will
always fail and we will never restrict the address on smaller devices.
- Additionally because of the extra page added by adding left_padding,
and how we only minimally restrict the vm, there's a chance we restrict
the vm only enough for the correctly calculated size of shadow. In these
cases, restricting the vm max address and will always fail due to the
extra page added to space size.

credit to @delcypher for the left_padding diagnosis, remembered his old
radar and PR when investigating this. https://reviews.llvm.org/D85389

Will monitor closely for fall out.

rdar://66603866
1 file changed
tree: 289568954873cbea5b58f3d3a0b026670482e342
  1. .ci/
  2. .github/
  3. bolt/
  4. clang/
  5. clang-tools-extra/
  6. cmake/
  7. compiler-rt/
  8. cross-project-tests/
  9. flang/
  10. libc/
  11. libclc/
  12. libcxx/
  13. libcxxabi/
  14. libunwind/
  15. lld/
  16. lldb/
  17. llvm/
  18. llvm-libgcc/
  19. mlir/
  20. offload/
  21. openmp/
  22. polly/
  23. pstl/
  24. runtimes/
  25. third-party/
  26. utils/
  27. .clang-format
  28. .clang-tidy
  29. .git-blame-ignore-revs
  30. .gitattributes
  31. .gitignore
  32. .mailmap
  33. CODE_OF_CONDUCT.md
  34. CONTRIBUTING.md
  35. LICENSE.TXT
  36. pyproject.toml
  37. README.md
  38. SECURITY.md
README.md

The LLVM Compiler Infrastructure

OpenSSF Scorecard OpenSSF Best Practices libc++

Welcome to the LLVM project!

This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.

The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.

C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.

Other components include: the libc++ C++ standard library, the LLD linker, and more.

Getting the Source Code and Building LLVM

Consult the Getting Started with LLVM page for information on building and running LLVM.

For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.

Getting in touch

Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.

The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.