Reword intro. (#48)

This adds a bit more precision and logical flow to the document.

Author: fmayer

src/mte.bib

@@ -21,3 +21,15 @@ @electronic{ZIMOP
   url = {https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc},
   year = {}
 }
+
+@electronic{LLVM_StackColoring,
+  title = {LLVM StackColoring.cpp},
+  url = {https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/StackColoring.cpp},
+  year = {}
+}
+
+@electronic{CppScope,
+  title = {cppreference.com - Scope},
+  url = {https://en.cppreference.com/w/cpp/language/scope.html},
+  year = {}
+}

src/mte_intro.adoc

@@ -1,77 +1,84 @@
 [[intro]]
 == Introduction
 
-Significant production deployed software is written in languages which provide
-powerful primitives (like C/C++) to software developers to manage memory.
+Significant production software is written in languages which provide
+powerful memory management primitives (like C/C++).
 Software is written in collaborative fashion and on tight deadlines and bugs do
-get introduced in software development. Such bugs sometimes can lead to issues
-like information disclosures, memory leak or memory corruptions commonly termed
-as `memory safety` issues. Underlying cause of memory safety issues can be
-anything but eventually such issues surface as invalid memory accesses.
+get introduced.
+A subset of these bugs introduce issues commonly termed as "memory safety"
+issues. The root causes of memory safety issues are numerous but eventually
+such issues surface as invalid memory accesses with regards to the
+language specification.
 
-From program's perspective access to memory happens via pointers and life cycle
-of pointers in a program is managed by following
+Programs use pointers to access memory. We refer to the parts of the programs
+in which accessing an object is valid as its "lifetime". An object's
+lifetime depends on the region of memory it is stored on:
 
-* Memory allocator - A memory allocator uses operating system facilities to
+* **Heap**: A memory allocator uses operating system facilities to
   create large memory mappings and expose APIs so that software can manage
   (allocate and free) memory at their convenience. As an example `malloc`
-  allocates memory and returns a pointer to allocated memory and `free` frees
-  the memory so that allocator can recycle that memory. Once a pointer is
-  created inside a function, it can pass around this pointer to other functions
-  or libraries and even after memory is freed, passed copies of pointer may
-  exist in other software components (due to bug) and if accessed can lead to
-  invalid memory access issues.
+  allocates a specified number of bytes and returns a pointer to the
+  allocated memory; `free` frees the memory so that allocator can recycle
+  that memory. Depending on the operating system, there might be many similar
+  APIs (e.g. `calloc`, `memalign`, etc.), but they are always paired with a
+  corresponding `free` call.
+  The lifetime of an object on the heap is between `malloc` (or similar) and
+  `free`.
 
-* Stack - Program starts execution with an allocated stack by underlying
-  execution environment which also ensures that stack pointer register is set
-  to base of stack memory and compiler derives all memory pointers for stack
-  objects (inside a function) from the stack pointer register. Program may be
-  written in a way which can pass around stack pointers to other functions. If
-  a passed copy of such a stack pointer is saved by another function and can be
-  accessed by it, then it may lead to stack invalid memory access issues.
+* **Stack**: The operating system allocates a region to be used as the stack of
+  the program. When a function is called, a stack frame is created at the top
+  of the stack. This is used to hold local variables, which are accessed
+  relative to the stack pointer, which designates the top of the stack.
+  Upon return from the function, the frame is popped from the stack by
+  adjusting the stack pointer. Within a stack frame, the compiler can reuse
+  the same memory for local variables that have non-overlapping lifetimes
+  (known as stack coloring, implemented e.g. in LLVM StackColoring
+  cite:[LLVM_StackColoring]). The lifetime of an object on the stack is
+  governed by the programming language's scoping rules (e.g. C++ scoping rules
+  cite:[CppScope]).
 
-* Globals - Pointers to global memory are valid throughout the runtime of the
-  program and thus invalid memory access to global memory is not possible.
-  Although if a program is accessing global memory in a way that can lead to
-  out of bounds access, that can be leveraged to access address space of the
-  program which otherwise wasn’t possible.
+* **Globals**: Storage for global variables is allocated by the operating system
+  on process startup (or when the dynamic object is loaded). Generally, the
+  storage for globals is destroyed on process shutdown (depending on the OS,
+  `dlclose` might cause it to be destoyed earlier).
+  The lifetime of a global ends when the process is terminated, or the dynamic
+  object is unloaded.
 
-Two prominent patterns of invalid memory accesses are following (but not
-limited to)
+In addition, an object has a size that represents the amount of memory
+allocated for it, and except for reassignment, a pointer must always point to
+memory of the object it was previously assigned to point to.
 
-* Stale pointer accesses (temporal): Memory was freed (heap) or became out of
-  scope (stack) and due to a bug in software, pointer is still kept around and
-  reachable via some control flow. This can be termed as use after free or out
-  of scope accesses. With respect to heap memory such issues are commonly
-  called `use after free` (UAF). In case of stack, such issues are termed as
-  `stack use after return`, `stack use after scope`.
+Two prominent patterns of invalid memory accesses are:
 
-* Incorrect pointer construction (spatial): Due to bug in bounds checking, an
-  incorrect pointer can be constructed and thus leading to invalid memory
-  access. Similarly due to a bug in arithmetics (integer overflow) or bad
-  casting (signed to unsigned), bad offsets can be generated and eventually
-  leading to incorrect pointer construction and out of bounds accesses. More
-  commonly they are termed `stack` or `heap buffer overflows`.
+* **Temporal**: A pointer is dereferenced past the lifetime of the object
+  it refers to. With respect to heap memory, such issues are commonly
+  called "use after free" (UAF). In case of stack, such issues are termed as
+  "stack use after return", "stack use after scope".
 
-To catch such inadvertent programming errors, performing memory validity check
-at access time is required. When the memory is valid to access (as an example
-after allocation in `malloc` or on a function call for stack locals),
-software can associate a `tag` value with the memory, store assigned `tag` in a
-special memory (tag storage) and annotate that `tag` in high unused bits of the
-pointer. This ensures that whenever the pointer is passed around, pointer is
-always tagged with `tag` assigned at the time when memory became valid. When
-memory is not allowed to be accessible (as an example in when memory is freed
-using `free` or stack locals are out of scope after a function has returned)
-then software can change assigned `tag` in tag storage. On a memory access (i.e
-pointer dereference), `tag` in pointer is checked against stored `tag` for that
-memory and if tags do not match then it is due to a memory safety bug in
-program.
+* **Spatial**: A pointer outside of the bounds of the object it refers to
+  be created, leading to invalid memory access when dereferenced. This is
+  commonly referred to as a "buffer overflow" (sometimes also "buffer
+  underflow"), or "out of bounds".
 
-Existing software mechanisms using compiler assisted software instrumentation
-and runtime support exist:
+To catch these issues, we can check memory accesses for validity at runtime.
+We do this by employing a lock and key scheme. Memory is assigned a memory tag
+(lock). Each pointer is assigned a pointer tag (key) in its unused top bits.
+On access, the key needs to match the lock, or the program is terminated.
 
-* HWAddressSanitizer (HWAsan) cite:[HWASAN] which uses pointer-masking.
-* AddressSanitizer (ASan) cite:[ASAN] which is fully implemented in software.
+When the lifetime of an object starts (e.g. `malloc` is called), we assign the
+same tag as a memory tag (lock) for the `size` bytes representing the object,
+and pointer tag (key). Subsequent in-bounds accesses using that pointer are
+valid. When the lifetime of the object ends (e.g. `free` is called), we change the
+memory tag (lock). Subsequent accesses through the pointer (which remains
+unchanged) will be invalid and terminate the program.
+
+Existing software mechanisms using compiler instrumentation and runtime
+support exist:
+
+* HWAddressSanitizer (HWAsan) cite:[HWASAN] which uses pointer-masking to
+  implement the idea explained above.
+* AddressSanitizer (ASan) cite:[ASAN] which is fully implemented in software,
+  but in a different way to the idea above.
 
 However software approach has significant cost from performance perspective and
 are mostly limited to unit test, developer test or special test harness (like