445 lines
18 KiB
HTML
445 lines
18 KiB
HTML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
|
|
<head>
|
|
<!-- 2025-02-13 Thu 11:16 -->
|
|
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
<title>‎</title>
|
|
<meta name="author" content="Akilan" />
|
|
<meta name="generator" content="Org Mode" />
|
|
<style>
|
|
#content { max-width: 60em; margin: auto; }
|
|
.title { text-align: center;
|
|
margin-bottom: .2em; }
|
|
.subtitle { text-align: center;
|
|
font-size: medium;
|
|
font-weight: bold;
|
|
margin-top:0; }
|
|
.todo { font-family: monospace; color: red; }
|
|
.done { font-family: monospace; color: green; }
|
|
.priority { font-family: monospace; color: orange; }
|
|
.tag { background-color: #eee; font-family: monospace;
|
|
padding: 2px; font-size: 80%; font-weight: normal; }
|
|
.timestamp { color: #bebebe; }
|
|
.timestamp-kwd { color: #5f9ea0; }
|
|
.org-right { margin-left: auto; margin-right: 0px; text-align: right; }
|
|
.org-left { margin-left: 0px; margin-right: auto; text-align: left; }
|
|
.org-center { margin-left: auto; margin-right: auto; text-align: center; }
|
|
.underline { text-decoration: underline; }
|
|
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
|
|
p.verse { margin-left: 3%; }
|
|
pre {
|
|
border: 1px solid #e6e6e6;
|
|
border-radius: 3px;
|
|
background-color: #f2f2f2;
|
|
padding: 8pt;
|
|
font-family: monospace;
|
|
overflow: auto;
|
|
margin: 1.2em;
|
|
}
|
|
pre.src {
|
|
position: relative;
|
|
overflow: auto;
|
|
}
|
|
pre.src:before {
|
|
display: none;
|
|
position: absolute;
|
|
top: -8px;
|
|
right: 12px;
|
|
padding: 3px;
|
|
color: #555;
|
|
background-color: #f2f2f299;
|
|
}
|
|
pre.src:hover:before { display: inline; margin-top: 14px;}
|
|
/* Languages per Org manual */
|
|
pre.src-asymptote:before { content: 'Asymptote'; }
|
|
pre.src-awk:before { content: 'Awk'; }
|
|
pre.src-authinfo::before { content: 'Authinfo'; }
|
|
pre.src-C:before { content: 'C'; }
|
|
/* pre.src-C++ doesn't work in CSS */
|
|
pre.src-clojure:before { content: 'Clojure'; }
|
|
pre.src-css:before { content: 'CSS'; }
|
|
pre.src-D:before { content: 'D'; }
|
|
pre.src-ditaa:before { content: 'ditaa'; }
|
|
pre.src-dot:before { content: 'Graphviz'; }
|
|
pre.src-calc:before { content: 'Emacs Calc'; }
|
|
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
|
|
pre.src-fortran:before { content: 'Fortran'; }
|
|
pre.src-gnuplot:before { content: 'gnuplot'; }
|
|
pre.src-haskell:before { content: 'Haskell'; }
|
|
pre.src-hledger:before { content: 'hledger'; }
|
|
pre.src-java:before { content: 'Java'; }
|
|
pre.src-js:before { content: 'Javascript'; }
|
|
pre.src-latex:before { content: 'LaTeX'; }
|
|
pre.src-ledger:before { content: 'Ledger'; }
|
|
pre.src-lisp:before { content: 'Lisp'; }
|
|
pre.src-lilypond:before { content: 'Lilypond'; }
|
|
pre.src-lua:before { content: 'Lua'; }
|
|
pre.src-matlab:before { content: 'MATLAB'; }
|
|
pre.src-mscgen:before { content: 'Mscgen'; }
|
|
pre.src-ocaml:before { content: 'Objective Caml'; }
|
|
pre.src-octave:before { content: 'Octave'; }
|
|
pre.src-org:before { content: 'Org mode'; }
|
|
pre.src-oz:before { content: 'OZ'; }
|
|
pre.src-plantuml:before { content: 'Plantuml'; }
|
|
pre.src-processing:before { content: 'Processing.js'; }
|
|
pre.src-python:before { content: 'Python'; }
|
|
pre.src-R:before { content: 'R'; }
|
|
pre.src-ruby:before { content: 'Ruby'; }
|
|
pre.src-sass:before { content: 'Sass'; }
|
|
pre.src-scheme:before { content: 'Scheme'; }
|
|
pre.src-screen:before { content: 'Gnu Screen'; }
|
|
pre.src-sed:before { content: 'Sed'; }
|
|
pre.src-sh:before { content: 'shell'; }
|
|
pre.src-sql:before { content: 'SQL'; }
|
|
pre.src-sqlite:before { content: 'SQLite'; }
|
|
/* additional languages in org.el's org-babel-load-languages alist */
|
|
pre.src-forth:before { content: 'Forth'; }
|
|
pre.src-io:before { content: 'IO'; }
|
|
pre.src-J:before { content: 'J'; }
|
|
pre.src-makefile:before { content: 'Makefile'; }
|
|
pre.src-maxima:before { content: 'Maxima'; }
|
|
pre.src-perl:before { content: 'Perl'; }
|
|
pre.src-picolisp:before { content: 'Pico Lisp'; }
|
|
pre.src-scala:before { content: 'Scala'; }
|
|
pre.src-shell:before { content: 'Shell Script'; }
|
|
pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
|
|
/* additional language identifiers per "defun org-babel-execute"
|
|
in ob-*.el */
|
|
pre.src-cpp:before { content: 'C++'; }
|
|
pre.src-abc:before { content: 'ABC'; }
|
|
pre.src-coq:before { content: 'Coq'; }
|
|
pre.src-groovy:before { content: 'Groovy'; }
|
|
/* additional language identifiers from org-babel-shell-names in
|
|
ob-shell.el: ob-shell is the only babel language using a lambda to put
|
|
the execution function name together. */
|
|
pre.src-bash:before { content: 'bash'; }
|
|
pre.src-csh:before { content: 'csh'; }
|
|
pre.src-ash:before { content: 'ash'; }
|
|
pre.src-dash:before { content: 'dash'; }
|
|
pre.src-ksh:before { content: 'ksh'; }
|
|
pre.src-mksh:before { content: 'mksh'; }
|
|
pre.src-posh:before { content: 'posh'; }
|
|
/* Additional Emacs modes also supported by the LaTeX listings package */
|
|
pre.src-ada:before { content: 'Ada'; }
|
|
pre.src-asm:before { content: 'Assembler'; }
|
|
pre.src-caml:before { content: 'Caml'; }
|
|
pre.src-delphi:before { content: 'Delphi'; }
|
|
pre.src-html:before { content: 'HTML'; }
|
|
pre.src-idl:before { content: 'IDL'; }
|
|
pre.src-mercury:before { content: 'Mercury'; }
|
|
pre.src-metapost:before { content: 'MetaPost'; }
|
|
pre.src-modula-2:before { content: 'Modula-2'; }
|
|
pre.src-pascal:before { content: 'Pascal'; }
|
|
pre.src-ps:before { content: 'PostScript'; }
|
|
pre.src-prolog:before { content: 'Prolog'; }
|
|
pre.src-simula:before { content: 'Simula'; }
|
|
pre.src-tcl:before { content: 'tcl'; }
|
|
pre.src-tex:before { content: 'TeX'; }
|
|
pre.src-plain-tex:before { content: 'Plain TeX'; }
|
|
pre.src-verilog:before { content: 'Verilog'; }
|
|
pre.src-vhdl:before { content: 'VHDL'; }
|
|
pre.src-xml:before { content: 'XML'; }
|
|
pre.src-nxml:before { content: 'XML'; }
|
|
/* add a generic configuration mode; LaTeX export needs an additional
|
|
(add-to-list 'org-latex-listings-langs '(conf " ")) in .emacs */
|
|
pre.src-conf:before { content: 'Configuration File'; }
|
|
|
|
table { border-collapse:collapse; }
|
|
caption.t-above { caption-side: top; }
|
|
caption.t-bottom { caption-side: bottom; }
|
|
td, th { vertical-align:top; }
|
|
th.org-right { text-align: center; }
|
|
th.org-left { text-align: center; }
|
|
th.org-center { text-align: center; }
|
|
td.org-right { text-align: right; }
|
|
td.org-left { text-align: left; }
|
|
td.org-center { text-align: center; }
|
|
dt { font-weight: bold; }
|
|
.footpara { display: inline; }
|
|
.footdef { margin-bottom: 1em; }
|
|
.figure { padding: 1em; }
|
|
.figure p { text-align: center; }
|
|
.equation-container {
|
|
display: table;
|
|
text-align: center;
|
|
width: 100%;
|
|
}
|
|
.equation {
|
|
vertical-align: middle;
|
|
}
|
|
.equation-label {
|
|
display: table-cell;
|
|
text-align: right;
|
|
vertical-align: middle;
|
|
}
|
|
.inlinetask {
|
|
padding: 10px;
|
|
border: 2px solid gray;
|
|
margin: 10px;
|
|
background: #ffffcc;
|
|
}
|
|
#org-div-home-and-up
|
|
{ text-align: right; font-size: 70%; white-space: nowrap; }
|
|
textarea { overflow-x: auto; }
|
|
.linenr { font-size: smaller }
|
|
.code-highlighted { background-color: #ffff00; }
|
|
.org-info-js_info-navigation { border-style: none; }
|
|
#org-info-js_console-label
|
|
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
|
|
.org-info-js_search-highlight
|
|
{ background-color: #ffff00; color: #000000; font-weight: bold; }
|
|
.org-svg { }
|
|
</style>
|
|
<script>
|
|
window.MathJax = {
|
|
tex: {
|
|
ams: {
|
|
multlineWidth: '85%'
|
|
},
|
|
tags: 'ams',
|
|
tagSide: 'right',
|
|
tagIndent: '.8em'
|
|
},
|
|
chtml: {
|
|
scale: 1.0,
|
|
displayAlign: 'center',
|
|
displayIndent: '0em'
|
|
},
|
|
svg: {
|
|
scale: 1.0,
|
|
displayAlign: 'center',
|
|
displayIndent: '0em'
|
|
},
|
|
output: {
|
|
font: 'mathjax-modern',
|
|
displayOverflow: 'overflow'
|
|
}
|
|
};
|
|
</script>
|
|
|
|
<script
|
|
id="MathJax-script"
|
|
async
|
|
src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js">
|
|
</script>
|
|
</head>
|
|
<body>
|
|
<div id="content" class="content">
|
|
<div id="table-of-contents" role="doc-toc">
|
|
<h2>Table of Contents</h2>
|
|
<div id="text-table-of-contents" role="doc-toc">
|
|
<ul>
|
|
<li><a href="#org2c44245">1. Fat-pointer Address Translations</a>
|
|
<ul>
|
|
<li><a href="#orge791f4e">1.1. Encoding Ranges as Bounds to the Pointer</a></li>
|
|
<li><a href="#org4a57a8a">1.2. Instrumenting Block-Based Allocators with Physically Contiguous Memory</a></li>
|
|
<li><a href="#org63c7417">1.3. Sample memory allocator Implementation</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div id="outline-container-org2c44245" class="outline-2">
|
|
<h2 id="org2c44245"><span class="section-number-2">1.</span> Fat-pointer Address Translations</h2>
|
|
<div class="outline-text-2" id="text-1">
|
|
<p>
|
|
Fat-pointer Address Translations, combined with the capabilities of the CHERI (Capability Hardware Enhanced RISC Instructions)
|
|
architecture, introduce robust memory safety and security features by incorporating additional metadata
|
|
with memory pointers. This enhanced architecture utilizes concepts such as FlexPointer,
|
|
Range Memory Mapping (RMM) to manage memory effectively.
|
|
</p>
|
|
|
|
<p>
|
|
Range addresses play a pivotal role within this implementation, defining memory
|
|
regions bounded by a starting address (Upper) and an ending address (Lower).
|
|
These range addresses are encoded within FAT-pointers, allowing for precise
|
|
control over memory regions.
|
|
</p>
|
|
|
|
|
|
<div id="org37578e7" class="figure">
|
|
<p><img src="diagram/HighOverviewArchitecture.drawio.png" alt="HighOverviewArchitecture.drawio.png" />
|
|
</p>
|
|
<p><span class="figure-number">Figure 1: </span>High overview architecture</p>
|
|
</div>
|
|
|
|
<p>
|
|
Figure <a href="#org37578e7">1</a> illustrates
|
|
the methodology employed to leverage the CHERI
|
|
128-bit FAT-pointer scheme for facilitating
|
|
block-based memory management on physically
|
|
contiguous memory,which is depicted on the
|
|
right side of the figure.
|
|
This technique contrasts with the
|
|
conventional approach.
|
|
</p>
|
|
|
|
<p>
|
|
We explore how using Huge pages
|
|
with CHERI bounds can reduce the
|
|
number of TLB entries required.
|
|
</p>
|
|
|
|
<p>
|
|
The functionality of ranges encompasses
|
|
several key aspects:
|
|
</p>
|
|
</div>
|
|
|
|
<div id="outline-container-orge791f4e" class="outline-3">
|
|
<h3 id="orge791f4e"><span class="section-number-3">1.1.</span> Encoding Ranges as Bounds to the Pointer</h3>
|
|
<div class="outline-text-3" id="text-1-1">
|
|
|
|
<div id="orgc38e57b" class="figure">
|
|
<p><img src="diagram/AllocationOverview24.png" alt="AllocationOverview24.png" />
|
|
</p>
|
|
<p><span class="figure-number">Figure 2: </span>Range of memory</p>
|
|
</div>
|
|
|
|
<p>
|
|
Integrating range bounds directly into FAT-pointers enables the architecture
|
|
to enforce memory access restrictions at the pointer level thus allowing
|
|
tracking of memory ranges on a pointer level. In this implementation, memory ranges are established using
|
|
bounds encoded within the FAT-pointer, adhering to the CHERI
|
|
128-bit bounds compression scheme\cite{woodruff_cheri_2019}.
|
|
</p>
|
|
|
|
<p>
|
|
Figure <a href="#orgc38e57b">2</a> illustrates a straightforward use-case in which the dark pink line represents a single,
|
|
large contiguous memory area, or huge page. Within this huge page, the orange and blue lines indicate
|
|
two separate memory allocations equivalent to invoking malloc twice to allocate memory in distinct regions.
|
|
This scenario simulates a block-based memory allocator operating within the confines of the huge page.
|
|
The allocations leverage the bounds encoded in the FAT-pointer, ensuring tracking and efficient
|
|
management of the allocated memory regions. By using the FAT-pointer bounds, this method maintains the
|
|
integrity and contiguity of the allocated blocks within the huge page.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div id="outline-container-org4a57a8a" class="outline-3">
|
|
<h3 id="org4a57a8a"><span class="section-number-3">1.2.</span> Instrumenting Block-Based Allocators with Physically Contiguous Memory</h3>
|
|
<div class="outline-text-3" id="text-1-2">
|
|
|
|
<div id="org2ea620c" class="figure">
|
|
<p><img src="diagram/TLBAccess.drawio.png" alt="TLBAccess.drawio.png" />
|
|
</p>
|
|
<p><span class="figure-number">Figure 3: </span>Fat-pointer Address Translations using huge pages</p>
|
|
</div>
|
|
|
|
<p>
|
|
Traditional address translation methods rely on hierarchical
|
|
structures to map virtual addresses to physical addresses.
|
|
This often requires multiple entries to handle different
|
|
memory segments, which increases overhead and adds complexity
|
|
to the translation process. In contrast, the current approach
|
|
simplifies this by using a single TLB (Translation Lookaside Buffer)
|
|
entry to translate multiple addresses within a contiguous memory
|
|
range. This reduces the number of TLB entries needed, making the
|
|
translation process more efficient and less complex.
|
|
</p>
|
|
|
|
<p>
|
|
By consolidating address translations into a single TLB entry,
|
|
this method cuts down on the overhead of managing many entries.
|
|
It also takes advantage of the bounds encoded within fat-pointers
|
|
to track and access memory more efficiently. This streamlined
|
|
approach allows for precise and effective memory management,
|
|
especially within large, contiguous memory regions like huge pages.
|
|
Overall, it simplifies memory operations while improving performance
|
|
and reduces TLB overhead by reducing TLB walks.
|
|
</p>
|
|
|
|
<p>
|
|
Figure <a href="#org2ea620c">3</a> illustrates a use-case of huge pages where the green
|
|
line represents a sample access to read within a contigous
|
|
space of physical memory. The dotted lines represents the
|
|
bounds for that particular pointer access. Using bounds
|
|
stored on the pointer a block based pattern can be reprecated
|
|
on physically contigous memory.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div id="outline-container-org63c7417" class="outline-3">
|
|
<h3 id="org63c7417"><span class="section-number-3">1.3.</span> Sample memory allocator Implementation</h3>
|
|
<div class="outline-text-3" id="text-1-3">
|
|
<p>
|
|
This section presents a straightforward memory allocator designed and implemented based on the
|
|
principles outlined in our approach. The allocator consists of three core functions: InitAlloc,
|
|
malloc, and free. The InitAlloc function initializes the memory pool, setting up the necessary
|
|
data structures and metadata required for efficient memory management. The malloc function is
|
|
responsible for allocating a contiguous block of memory of a specified size, while the free
|
|
function deallocates the memory, returning it to the pool for future use.
|
|
</p>
|
|
|
|
<p>
|
|
A notable feature of this malloc implementation is its compatibility with kernel modules,
|
|
where it can be integrated as an alternative to the mmap system call. This integration
|
|
ensures that memory allocations are physically contiguous, a critical requirement for
|
|
certain low-level operations and hardware interactions. By providing physically contiguous
|
|
memory blocks, this allocator can serve as a foundational layer for standard block-based allocators,
|
|
such as Jemalloc, enabling them to operate efficiently in environments where physical memory
|
|
contiguity is essential.
|
|
</p>
|
|
|
|
<p>
|
|
Algorithm 1 describes the initialization of physically contiguous memory through the use of huge pages,
|
|
a mechanism supported by modern architectures to optimize memory management. The algorithm begins by
|
|
allocating a fixed block of 1 GB of physically contiguous memory. This decision is driven by the
|
|
architectural constraints of contemporary systems, particularly ARM-based CPUs, where 1 GB represents
|
|
the largest supported page size. By leveraging huge pages, the algorithm reduces the overhead associated
|
|
with page table management and enhances memory access efficiency, which is critical for performance-sensitive
|
|
applications and kernel-level operations.
|
|
</p>
|
|
|
|
<p>
|
|
When the malloc function is invoked, the algorithm employs an eager allocation strategy for physical memory.
|
|
This is achieved through the use of the SetBounds mechanism, which constructs a FAT-pointer—a specialized
|
|
pointer that encodes both the start and end addresses of the allocated memory region within the pointer
|
|
itself. The start and end addresses correspond to the size of the memory block requested by malloc. This
|
|
approach introduces a method of memory tracking, where the bounds of the allocated region are
|
|
explicitly encoded in the address, enabling efficient monitoring and management of memory usage.
|
|
</p>
|
|
|
|
<p>
|
|
Furthermore, this design leverages shared huge page TLB (Translation Lookaside Buffer) entries to map
|
|
and track memory addresses. By encoding bounds directly into the address, the algorithm ensures that memory
|
|
accesses remain within the allocated region, thereby enhancing safety and reducing the risk of out-of-bounds
|
|
errors. This use of FAT-pointers and shared TLB entries not only aligns with the principles of
|
|
efficient memory management but also demonstrates a practical usecase of huge pages in CHERI.
|
|
</p>
|
|
|
|
<p>
|
|
The memory deallocation mechanism in the proposed allocator is facilitated by the FAT-pointer structure
|
|
introduced in the malloc algorithm. When the free function is invoked, it utilizes the metadata
|
|
embedded within the FAT-pointer to determine the range and size of the allocated memory region.
|
|
Specifically, the start and end addresses encoded in the FAT-pointer provide the necessary information
|
|
to identify the exact memory block to be deallocated. This allows the allocator to precisely unmapped
|
|
the corresponding memory region from the address space, ensuring efficient and accurate memory management.
|
|
</p>
|
|
|
|
<p>
|
|
By extracting the bounds and size directly from the FAT-pointer, the free function eliminates the need
|
|
for additional metadata lookups or complex data structures, streamlining the deallocation process.
|
|
This approach not only enhances performance but also reduces the risk of memory leaks or fragmentation.
|
|
</p>
|
|
|
|
<p>
|
|
\bibliographystyle{IEEEtran}
|
|
\bibliography{FAT-Pointer.bib}
|
|
</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div id="postamble" class="status">
|
|
<p class="author">Author: Akilan</p>
|
|
<p class="date">Created: 2025-02-13 Thu 11:16</p>
|
|
<p class="validation"><a href="https://validator.w3.org/check?uri=referer">Validate</a></p>
|
|
</div>
|
|
</body>
|
|
</html> |