[all-commits] [llvm/llvm-project] b1751f: [lldb][Linux] Mark memory regions used for shadow ...

[David Spickett via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b1751faada35e3456b2a3f6b6c9559b5d74d559b
      https://github.com/llvm/llvm-project/commit/b1751faada35e3456b2a3f6b6c9559b5d74d559b
  Author: David Spickett <david.spickett at linaro.org>
  Date:   2025-01-14 (Tue, 14 Jan 2025)

  Changed paths:
    M lldb/include/lldb/Target/MemoryRegionInfo.h
    M lldb/packages/Python/lldbsuite/test/lldbtest.py
    M lldb/source/Commands/CommandObjectMemory.cpp
    M lldb/source/Plugins/Process/Utility/LinuxProcMaps.cpp
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
    M lldb/source/Target/MemoryRegionInfo.cpp
    A lldb/test/API/linux/aarch64/gcs/Makefile
    A lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
    A lldb/test/API/linux/aarch64/gcs/main.c
    M lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp
    M lldb/unittests/Process/Utility/MemoryTagManagerAArch64MTETest.cpp
    M lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
    M lldb/unittests/Process/minidump/MinidumpParserTest.cpp

  Log Message:
  -----------
  [lldb][Linux] Mark memory regions used for shadow stacks (#117861)

This is intended for use with Arm's Guarded Control Stack extension
(GCS). Which reuses some existing shadow stack support in Linux. It
should also work with the x86 equivalent.

A "ss" flag is added to the "VmFlags" line of shadow stack memory
regions in `/proc/<pid>/smaps`. To keep the naming generic I've called
it shadow stack instead of guarded control stack.

Also the wording is "shadow stack: yes" because the shadow stack region
is just where it's stored. It's enabled for the whole process or it
isn't. As opposed to memory tagging which can be enabled per region, so
"memory tagging: enabled" fits better for that.

I've added a test case that is also intended to be the start of a set of
tests for GCS. This should help me avoid duplicating the inline assembly
needed.

Note that no special compiler support is needed for the test. However,
for the intial enabling of GCS (assuming the libc isn't doing it) we do
need to use an inline assembly version of prctl.

This is because as soon as you enable GCS, all returns are checked
against the GCS. If the GCS is empty, the program will fault. In other
words, you can never return from the function that enabled GCS, unless
you push values onto it (which is possible but not needed here).

So you cannot use the libc's prctl wrapper for this reason. You can use
that wrapper for anything else, as we do to check if GCS is enabled.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications