[Lldb-commits] [lldb] [lldb] Don't use a vm addr range starting at 0 for local memory (PR #100288)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda created https://github.com/llvm/llvm-project/pull/100288

When an inferior stub cannot allocate memory for lldb, and lldb needs to store the result of expressions, it will do it in lldb's own memory range ("host memory").  But it needs to find a virtual address range that is not used in the inferior process.  It tries to use the qMemoryRegionInfo gdb remote serial protocol packet to find a range that is inaccessible, starting at address 0 and moving up the size of each region.

If the first region found at address 0 is inaccessible, lldb will use the address range starting at 0 to mean "read lldb's host memory, not the process memory", and programs that crash with a null dereference will have poor behavior.

This patch skips consideration of a memory region that starts at address 0.

I also clarified the documentation of qMemoryRegionInfo to make it clear that the stub is required to provide permissions for a memory range that is accessable, it is not an optional key in this response. This issue was originally found by a stub that did not list permissions in its response, and lldb treated the first region returned as the one it would use.  (the stub also didn't support the memory-allocate packet)

>From 28439443b9e44a242e59bf1cdd114486380d54fc Mon Sep 17 00:00:00 2001
From: Jason Molenda <jmolenda at apple.com>
Date: Tue, 23 Jul 2024 18:54:31 -0700
Subject: [PATCH] [lldb] Don't use a vm addr range starting at 0 for local
 memory

When an inferior stub cannot allocate memory for lldb, and lldb
needs to store the result of expressions, it will do it in lldb's
own memory range ("host memory").  But it needs to find a virtual
address range that is not used in the inferior process.  It tries
to use the qMemoryRegionInfo gdb remote serial protocol packet to
find a range that is inaccessible, starting at address 0 and moving
up the size of each region.

If the first region found at address 0 is inaccessible, lldb will
use the address range starting at 0 to mean "read lldb's host memory,
not the process memory", and programs that crash with a null
dereference will have poor behavior.

This patch skips consideration of a memory region that starts at
address 0.

I also clarified the documentation of qMemoryRegionInfo to make it
clear that the stub is required to provide permissions for a memory
range that is accessable, it is not an optional key in this response.
This issue was originally found by a stub that did not list
permissions, and lldb treated the first region returned as the one
it would use.
---
 lldb/docs/resources/lldbgdbremote.md   |  8 +++++++-
 lldb/source/Expression/IRMemoryMap.cpp | 17 ++++++++++++-----
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/lldb/docs/resources/lldbgdbremote.md b/lldb/docs/resources/lldbgdbremote.md
index 7076a75032dae..5cac3736337a8 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -1403,6 +1403,12 @@ For instance, with a macOS process which has nothing mapped in the first
 The lack of `permissions:` indicates that none of read/write/execute are valid
 for this region.
 
+The stub must include `permissions:` key-value on all memory ranges
+that are valid to access in the inferior process -- the lack of
+`permissions:` means that this is an inaccessible (no page table
+entries exist, in a system using VM) memory range.  If a stub cannot
+determine actual permissions, return `rwx`.
+
 **Priority To Implement:** Medium
 
 This is nice to have, but it isn't necessary. It helps LLDB
@@ -2434,4 +2440,4 @@ The `0x` prefixes are optional - like most of the gdb-remote packets,
 omitting them will work fine; these numbers are always base 16.
 
 The length of the payload is not provided.  A reliable, 8-bit clean,
-transport layer is assumed.
\ No newline at end of file
+transport layer is assumed.
diff --git a/lldb/source/Expression/IRMemoryMap.cpp b/lldb/source/Expression/IRMemoryMap.cpp
index de631370bb048..bb3e4e0a9a9fc 100644
--- a/lldb/source/Expression/IRMemoryMap.cpp
+++ b/lldb/source/Expression/IRMemoryMap.cpp
@@ -84,7 +84,7 @@ lldb::addr_t IRMemoryMap::FindSpace(size_t size) {
   // any allocations.  Otherwise start at the beginning of memory.
 
   if (m_allocations.empty()) {
-    ret = 0x0;
+    ret = 0;
   } else {
     auto back = m_allocations.rbegin();
     lldb::addr_t addr = back->first;
@@ -116,10 +116,17 @@ lldb::addr_t IRMemoryMap::FindSpace(size_t size) {
     Status err = process_sp->GetMemoryRegionInfo(ret, region_info);
     if (err.Success()) {
       while (true) {
-        if (region_info.GetReadable() != MemoryRegionInfo::OptionalBool::eNo ||
-            region_info.GetWritable() != MemoryRegionInfo::OptionalBool::eNo ||
-            region_info.GetExecutable() !=
-                MemoryRegionInfo::OptionalBool::eNo) {
+        if (region_info.GetRange().GetRangeBase() == 0 &&
+            region_info.GetRange().GetRangeEnd() - 1 < end_of_memory) {
+          // Don't use a region that starts at address 0,
+          // that can mask null dereferences in the inferior.
+          ret = region_info.GetRange().GetRangeEnd();
+        } else if (region_info.GetReadable() !=
+                       MemoryRegionInfo::OptionalBool::eNo ||
+                   region_info.GetWritable() !=
+                       MemoryRegionInfo::OptionalBool::eNo ||
+                   region_info.GetExecutable() !=
+                       MemoryRegionInfo::OptionalBool::eNo) {
           if (region_info.GetRange().GetRangeEnd() - 1 >= end_of_memory) {
             ret = LLDB_INVALID_ADDRESS;
             break;