Cheri-research/snmalloc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix markdown (#522)

Browse Source 
* Fix markdown link to ./docs/AddressSpace

* Fix footnotes in docs/StrictProvenance.md
This commit is contained in:
Jakub Panek
2022-05-10 16:51:59 +02:00
committed by GitHub
parent d5c732f3c1
commit c4f31bb279
2 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -32,7 +32,7 @@ do not for snmalloc.
The implementation of snmalloc has evolved significantly since the [initial paper](snmalloc.pdf). The implementation of snmalloc has evolved significantly since the [initial paper](snmalloc.pdf).
The mechanism for returning memory to remote threads has remained, but most of the meta-data layout has changed. The mechanism for returning memory to remote threads has remained, but most of the meta-data layout has changed.
We recommend you read [docs/security](./docs/security/README.md) to find out about the current design, and We recommend you read [docs/security](./docs/security/README.md) to find out about the current design, and
if you want to dive into the code (./docs/AddressSpace.md) provides a good overview of the allocation and deallocation paths. if you want to dive into the code [docs/AddressSpace.md](./docs/AddressSpace.md) provides a good overview of the allocation and deallocation paths.
[![snmalloc CI](https://github.com/microsoft/snmalloc/actions/workflows/main.yml/badge.svg?branch=master)](https://github.com/microsoft/snmalloc/actions/workflows/main.yml) [![snmalloc CI](https://github.com/microsoft/snmalloc/actions/workflows/main.yml/badge.svg?branch=master)](https://github.com/microsoft/snmalloc/actions/workflows/main.yml)

8
docs/StrictProvenance.md
View File

@@ -89,7 +89,7 @@ For `malloc()` in particular, it is enormously beneficial to be able to impose b
(*Temporal* concerns still apply, in that live allocations can overlap prior, now-dead allocations. (*Temporal* concerns still apply, in that live allocations can overlap prior, now-dead allocations.
Stochastic defenses are employed within `snmalloc` and deterministic defenses are ongoing research at MSR.) Stochastic defenses are employed within `snmalloc` and deterministic defenses are ongoing research at MSR.)
Borrowing terminology from CHERI, we speak of the **authority** (to a subset of the address space) held by a pointer and will justify actions in terms of this authority. Borrowing terminology from CHERI, we speak of the **authority** (to a subset of the address space) held by a pointer and will justify actions in terms of this authority.[^mmu-perms]
While many kinds of authority can be envisioned, herein we will mean either While many kinds of authority can be envisioned, herein we will mean either
* *spatial* authority to read/write/execute within a single *interval* within the address space, or * *spatial* authority to read/write/execute within a single *interval* within the address space, or
@@ -203,14 +203,14 @@ The annotation `Bout` is *computed* as a function of `Bin`.
# Endnotes # Endnotes
[^mmu-perms] Pointer authority generally *intersects* with MMU-based authorization. [^mmu-perms]: Pointer authority generally *intersects* with MMU-based authorization.
For example, software using a pointer with both write and execute authority will still find that it cannot write to pages considered read-only by the MMU nor will it be able to execute non-executable pages. For example, software using a pointer with both write and execute authority will still find that it cannot write to pages considered read-only by the MMU nor will it be able to execute non-executable pages.
Generally speaking, `snmalloc` requires only read-write access to memory it manages and merely passes through other permissions, with the exception of *vmmap*, which it removes from any pointer it returns. Generally speaking, `snmalloc` requires only read-write access to memory it manages and merely passes through other permissions, with the exception of *vmmap*, which it removes from any pointer it returns.
[^amplifier-state] As we are largely following the fat pointer model and its evolution into CHERI capabilities, we achieve amplification through a *stateful*, *software* mechanism, rather than an architectural mechanism. [^amplifier-state]: As we are largely following the fat pointer model and its evolution into CHERI capabilities, we achieve amplification through a *stateful*, *software* mechanism, rather than an architectural mechanism.
Specifically, the amplification mechanism will retain a superset of any authority it may be asked to reconstruct. Specifically, the amplification mechanism will retain a superset of any authority it may be asked to reconstruct.
There have, in times past, been capability systems with architectural amplification (e.g., HYDRA's type-directed amplification), but we believe that future systems are unlikely to adopt this latter approach, necessitating the changes we propose below. There have, in times past, been capability systems with architectural amplification (e.g., HYDRA's type-directed amplification), but we believe that future systems are unlikely to adopt this latter approach, necessitating the changes we propose below.
[^bounds-precision] `StrictProvenance` architectures have historically differed in the precision with which authority can be represented. [^bounds-precision]: `StrictProvenance` architectures have historically differed in the precision with which authority can be represented.
Notably, it may not be possible to achieve byte-granular authority boundaries at every size scale. Notably, it may not be possible to achieve byte-granular authority boundaries at every size scale.
In the case of CHERI specifically, `snmalloc`'s size classes and its alignment policies are already much coarser than existing architectural requirements for representable authority on all existing implementations. In the case of CHERI specifically, `snmalloc`'s size classes and its alignment policies are already much coarser than existing architectural requirements for representable authority on all existing implementations.