[Doc] Fix main menu and links

Documentation/howto-doc.rst

@@ -1,4 +1,4 @@
-.. _doc-howto:
+.. _howto-doc:
 
 How to write documentation
 ==========================

Documentation/oldwiki/Debugging-Graphene.md

@@ -1,3 +1,6 @@
+# Debugging Graphene
+
+
 ## Running Graphene with GDB
 
 To enable GDB support, the PAL loader and Graphene implement the GDB protocol to notify the

Documentation/oldwiki/Graphene-Manifest-Syntax.md

@@ -1,3 +1,5 @@
+# Graphene Manifest Syntax
+
 ## Basic Syntax
 
 A manifest file is an application-specific configuration text file that specifies the environment

Documentation/oldwiki/Graphene-Quick-Start.md

@@ -1,3 +1,5 @@
+# Graphene Quick Start
+
 (The following quick start instruction does not include the steps for running Graphene with
 sandboxing because sandboxing is an experimental feature.)
 

Documentation/oldwiki/Graphene-SGX-Manifest-Syntax.md

@@ -1,4 +1,6 @@
-The basic manifest syntax for Graphene is described in [[Graphene Manifest Syntax]]. If Graphene
+# Graphene SGX Manifest Syntax
+
+The basic manifest syntax for Graphene is described in [Graphene Manifest Syntax](Graphene-Manifest-Syntax.md). If Graphene
 is *not* running with SGX, the SGX-specific syntax is ignored. All keys in the SGX-specific syntax
 are optional. If the keys are not specified, Graphene will use the default values.
 

Documentation/oldwiki/Graphene-SGX-Quick-Start.md

@@ -1,3 +1,5 @@
+# Graphene SGX Quick Start
+
 Before you run any applications in Graphene-SGX, please make sure that Intel SGX SDK and the SGX
 driver are installed on your system. We recommend using Intel SGX SDK and the SGX driver no older
 than version 2.1.

Documentation/oldwiki/Implementing-New-System-Calls-in-Graphene.md

@@ -1,3 +1,5 @@
+# Implementing New System Calls in Graphene
+
 ### Step 1: Define the Interface of System Call and Name the Function in `LibOS/shim/src/shim_syscalls.c`
 
 For example, assume we are implementing `sched_setaffinity`. You must find the definition of

Documentation/oldwiki/Introduction-to-Graphene-SGX.md

@@ -1,3 +1,5 @@
+# Introduction to Graphene SGX
+
 ## What is Intel SGX?
 
 SGX (Software Guard Extenstions) is a security feature of the latest Intel CPUs. According to
@@ -27,7 +29,7 @@ hashes and URIs of these binaries, is signed), similar to the Intel SGX SDK work
 
 ## How to Build Graphene with Intel SGX Support?
 
-Refer to the [[Quick Start | SGX Quick Start]] page on how to build and run Graphene-SGX.
+Refer to the [Quick Start](Graphene-SGX-Quick-Start.md) page on how to build and run Graphene-SGX.
 
 ### Prerequisites
 
@@ -38,7 +40,7 @@ users then ship the signed bundle to the untrusted host and run it inside the SG
 secure their workloads.
 
 The prerequisites to build Graphene are detailed in
-[[Prerequisites of Graphene | Home#what-is-the-prerequisite-of-running-my-applications-in-graphene]]).
+[Prerequisites of Graphene](Introduction-to-Graphene.html#prerequisites).
 
 ### Prerequisites for Developer
 
@@ -72,7 +74,7 @@ developer's machine. For security reasons, Graphene will not allow loading any b
 not signed/hashed.
 
 For applications that are prepared in the Graphene apps directory, such as GCC, Apache, and Bash
-(more are listed in [[Run Applications in Graphene]]), just type 'make SGX=1' in the corresponding
+(more are listed in [Run Applications in Graphene](Run-Applications-in-Graphene.md)), just type 'make SGX=1' in the corresponding
 directory. The scripts are automated to build the applications and sign their manifests in order
 to ship them to the untrusted host.
 

Documentation/oldwiki/Introduction-to-Graphene.md

@@ -1,3 +1,5 @@
+# Introduction to Graphene
+
 ## What is Graphene Library OS?
 
 **Graphene library OS** is a lightweight guest OS that supports Linux multi-process applications.
@@ -12,7 +14,7 @@ hardware-encrypted memory regions (called SGX enclaves). SGX protects code and d
 enclave against privileged software attacks and against physical attacks on the hardware off the
 CPU package (e.g., cold-boot attacks on RAM). Graphene is able to run unmodified applications
 inside SGX enclaves, without the toll of manually porting the application to the SGX environment.
-For more information about SGX support, see [[Introduction to Graphene-SGX]].
+For more information about SGX support, see [Introduction to Graphene-SGX](Introduction-to-Graphene-SGX.md).
 
 ### What Hosts Does Graphene Currently Run On?
 
@@ -20,7 +22,7 @@ Graphene was developed to encapsulate all host-specific code in one layer, calle
 Adaptation Layer, or PAL. Thus, if there is a PAL for a given host, the library OS and applications
 will "just work".
 
-Porting Graphene to a new host only requires porting a PAL, by implementing the [[PAL Host ABI]]
+Porting Graphene to a new host only requires porting a PAL, by implementing the [PAL Host ABI](PAL-Host-ABI.md)
 using OS features of the host. To date, we ported Graphene to FreeBSD and Linux (the latter also
 with Intel SGX support). Support for more hosts is expected in the future.
 
@@ -58,7 +60,7 @@ To run tests, you also need the python3-pytest package:
 
 ## Build and Run Graphene
 
-See [[Graphene Quick Start]] for instructions how to quickly build and run Graphene.
+See [Graphene Quick Start](Graphene-Quick-Start.md) for instructions how to quickly build and run Graphene.
 
 ### Obtain Source Code
 
@@ -80,7 +82,7 @@ To build Graphene with debug symbols, run `make DEBUG=1` instead of `make`. You
 downloading the Glibc sources, use `GLIBC_MIRRORS=...` when running `make`. To build with `-Werror`,
 run `make WERROR=1`.
 
-Currently, Graphene has implemented [[these Linux system calls|Supported System Calls in Graphene]].
+Currently, Graphene has implemented [these Linux system calls](Supported-System-Calls-in-Graphene.md).
 Before running any application, you must confirm that all system calls required by the application
 executables and libraries are supported (or that unsupported system calls do not affect the
 functionality of the application).
@@ -94,7 +96,7 @@ See [EXPERIMENTAL/linux-reference-monitor](https://github.com/oscarlab/graphene/
 
 ### Build with Intel SGX Support
 
-See [[Graphene-SGX Quick Start]] for instructions on how to build and run Graphene with
+See [Graphene-SGX Quick Start](Graphene-SGX-Quick-Start.md) for instructions on how to build and run Graphene with
 Intel SGX support.
 
 
@@ -182,10 +184,10 @@ applications such as GCC, Bash, Redis, R, and Apache. The manifest files for the
 provided in the individual directories under `LibOS/shim/test/apps`.
 
 For the full documentation of the Graphene manifest syntax, please see the following pages:
-[Graphene Manifest Syntax]] and [[Graphene-SGX Manifest Syntax]].
+[Graphene Manifest Syntax](Graphene-Manifest-Syntax.md) and [Graphene-SGX Manifest Syntax](Graphene-SGX-Manifest-Syntax.md).
 
 For more details about running tested/benchmarked applications in Graphene, please see this page:
-[[Run Applications in Graphene]].
+[Run Applications in Graphene](Run-Applications-in-Graphene.md).
 
 
 #### Run Built-in Examples in Graphene-SGX
@@ -223,8 +225,8 @@ For more details about running tested/benchmarked applications in Graphene, plea
 
 Some documentation that might be helpful:
 
-* [[PAL Host ABI]]
-* [[Porting Graphene PAL to Other hosts]]
+* [PAL Host ABI](PAL-Host-ABI.md)
+* [Porting Graphene PAL to Other hosts](Porting-Graphene-PAL-to-Other-hosts.md)
 
 ## How to Contact the Maintainers?
 

Documentation/oldwiki/PAL-Host-ABI.md

@@ -1,3 +1,5 @@
+# PAL Host ABI
+
 ## What is Graphene's PAL Host ABI
 
 PAL Host ABI is the interface used by Graphene to interact with its host. It is translated into
@@ -21,7 +23,7 @@ PAL APIs. PAL does not and will not resolve other unresolved symbols, so the loa
 executables must resolve them afterwards.
 
 After loading the binaries, PAL needs to load and interpret the manifest files. The manifest syntax
-is described in [[Graphene Manifest Syntax]].
+is described in [Graphene Manifest Syntax](Graphene-Manifest-Syntax.md).
 
 ### Manifest and Executable Loading Rules
 
@@ -200,7 +202,7 @@ and aligned at the allocation alignment.
 
 This API modifies the permissions of a previously allocated memory mapping. Both `addr` and
 `size` must be non-zero and aligned at the allocation alignment. `prot` is defined as
-[[DkVirtualMemoryAlloc|PAL Host ABI#DkVirtualMemoryAlloc]].
+[DkVirtualMemoryAlloc](#dkvirtualmemoryalloc).
 
 ### Process Creation
 
@@ -318,7 +320,7 @@ write-side only, or both if 0 is given.
 This API maps a file to a virtual memory address in the current process. `address` can be NULL or
 a valid address that is aligned at the allocation alignment. `offset` and `size` have to be non-zero
 and aligned at the allocation alignment. `prot` is defined as
-[[DkVirtualMemoryAlloc|PAL Host ABI#DkVirtualMemoryAlloc]].
+[DkVirtualMemoryAlloc](#dkvirtualmemoryalloc).
 
 #### DkStreamUnmap
 
@@ -580,7 +582,7 @@ This API returns CPUID information in the array `values`, based on the leaf/subl
 
 This API creates a physical memory channel for the process to copy virtual memory as copy-on-write.
 Once a channel is created, other processes can connect to the physical memory channel by using
-[[DkStreamOpen|PAL Host ABI#DkStreamOpen]] with a URI `gipc:<key>`.
+[DkStreamOpen](#dkstreamopen) with a URI `gipc:<key>`.
 
 #### DkPhysicalMemoryCommit
 

Documentation/oldwiki/Porting-Graphene-PAL-to-Other-hosts.md

@@ -1,3 +1,5 @@
+# Porting Graphene PAL to Other hosts
+
 ## Platform Compatibility of Graphene
 
 Graphene adopts a similar architecture to the Drawbridge Library OS, which runs a generic library
@@ -9,7 +11,7 @@ for this new host.
 
 To port Graphene to a new host platform, the only effort required is reimplementing the PAL on the
 desired host platform. Most of the implementation should be as simple as translating the PAL API
-to the native system interface of the host. The implemented PAL must support [[PAL Host ABI]].
+to the native system interface of the host. The implemented PAL must support [PAL Host ABI](PAL-Host-ABI.md).
 
 In fact, even in the PAL source code, we expect part of the code to be host-generic. To make porting
 Graphene easier, we deliberately separate the source code of PAL into three parts:

Documentation/oldwiki/Process-Creation-in-Graphene-SGX.md

@@ -1,7 +1,9 @@
+# Process Creation in Graphene SGX
+
 (Disclaimer: This explanation is partially outdated. It is intended only as an internal
 reference for developers of Graphene, not as a general documentation for Graphene users.)
 
-# Fork in Graphene-SGX
+## Fork in Graphene-SGX
 
 Fork() system call is intercepted in the `shim_do_fork()` LibOS function. This function performs
 three tasks: (1) discovers the namespace leader, (2) creates a LibOS `shim_thread` structure for
@@ -9,7 +11,7 @@ a new thread, and (3) calls `do_migrate_process()`. The first two tasks are triv
 concentrate on the third one.
 
 
-## Parent: Fork via `do_migrate_process`
+### Parent: Fork via `do_migrate_process`
 
 The function `do_migrate_process()` creates a new process in the underlying OS, establishes a
 channel between the current process and the newly created child process, collects checkpoint data
@@ -44,7 +46,7 @@ faster than normal Unix streams. However, SGX PAL does not support GIPC. Thus, t
 sending to the child is done via a Unix stream.
 
 
-## Child: Initialization after Fork
+### Child: Initialization after Fork
 
 After the child is created, Pal-Linux-SGX enters the enclave using EENTER. The enclave code calls
 `pal_linux_main()` which in turn calls `init_child_process()`. The `init_child_process()` function

Documentation/oldwiki/Run-Applications-in-Graphene-SGX.md

@@ -1,13 +1,15 @@
+# Run Applications in Graphene SGX
+
 We prepared and tested several applications to demonstrate Graphene-SGX usability. These applications
 can be directly built and run from the Graphene source:
 
-* [[LMBench (v2.5) | Run Applications in Graphene SGX#running lmbench in graphene]]
-* [[Python | Run Applications in Graphene SGX#running python in graphene]]
-* [[R | Run Applications in Graphene SGX#running r in graphene]]
-* [[Lighttpd | Run Applications in Graphene SGX#running lighttpd in graphene]]
-* [[Apache | Run Applications in Graphene SGX#running apache in graphene]]
-* [[Busybox | Run Applications in Graphene SGX#running busybox in graphene]]
-* [[Bash | Run Applications in Graphene SGX#running bash in graphene]]
+* [LMBench (v2.5)](#running-lmbench-in-graphene-sgx)
+* [Python](#running-python-in-graphene-sgx)
+* [R](#running-r-in-graphene-sgx)
+* [Lighttpd](#running-lighttpd-in-graphene-sgx)
+* [Apache](#running-apache-in-graphene-sgx)
+* [Busybox](#running-busybox-in-graphene-sgx)
+* [Bash](#running-bash-in-graphene-sgx)
 
 
 ## Running LMBench in Graphene-SGX
@@ -111,7 +113,7 @@ Apache, run the following commands:
 
 The commands above will compile the source code, build the manifest file for Graphene, generate
 the configuration file for Apache, and generate the HTML sample files (same as described in the
-[[lighttpd section|Run applications in Graphene#Running Lighttpd in Graphene]]).
+[lighttpd section](#running-lighttpd-in-graphene-sgx)).
 
 The server can be started manually via one of the following commands:
 

Documentation/oldwiki/Run-Applications-in-Graphene.md

@@ -1,14 +1,16 @@
+# Run Applications in Graphene
+
 We prepared and tested several applications to demonstrate Graphene usability. These applications
 can be directly built and run from the Graphene source:
 
-* [[LMBench (v2.5) | Run Applications in Graphene#running lmbench in graphene]]
-* [[Python | Run Applications in Graphene#running python in graphene]]
-* [[R | Run Applications in Graphene#running r in graphene]]
-* [[GCC | Run Applications in Graphene#running gcc in graphene ]]
-* [[Lighttpd | Run Applications in Graphene#running lighttpd in graphene]]
-* [[Apache | Run Applications in Graphene#running apache in graphene]]
-* [[Busybox | Run Applications in Graphene#running busybox in graphene]]
-* [[Bash | Run Applications in Graphene#running bash in graphene]]
+* [LMBench (v2.5)](#running-lmbench-in-graphene)
+* [Python](#running-python-in-graphene)
+* [R](#running-r-in-graphene)
+* [GCC](#running-gcc-in-graphene)
+* [Lighttpd](#running-lighttpd-in-graphene)
+* [Apache](#running-apache-in-graphene)
+* [Busybox](#running-busybox-in-graphene)
+* [Bash](#running-bash-in-graphene)
 
 ## Running LMBench in Graphene
 
@@ -131,7 +133,7 @@ Apache, run the following command:
 
 The commands above will compile the source code, build the manifest file for Graphene, generate
 the configuration file for Apache, and generate the HTML sample files (same as described in the
-[[lighttpd section|Run applications in Graphene#Running Lighttpd in Graphene]]).
+[lighttpd section](#running-lighttpd-in-graphene)).
 
 The server can be started manually via one of the following commands:
 

Documentation/oldwiki/Signal-Handling-in-Graphene.md

@@ -1,7 +1,9 @@
+# Signal Handling in Graphene
+
 (Disclaimer: This explanation is partially outdated. It is intended only as an internal
 reference for developers of Graphene, not as a general documentation for Graphene users.)
 
-# Signal Handling
+## Signal Handling
 
 This analysis is written while Graphene's signal handling mechanisms are in flux. In future, all
 Graphene PALs should implement the same mechanism, and LibOS should adopt a better scheme to
@@ -49,9 +51,9 @@ in contrast to current LibOS approach of (1) delivering the first signal even in
 emulated syscall, and (2) pending nested signals until system-call completion.
 
 
-## Linux-SGX PAL Flows
+### Linux-SGX PAL Flows
 
-### Initialization of Signal Handling
+#### Initialization of Signal Handling
 
 ```
   Normal context
@@ -93,7 +95,7 @@ emulated syscall, and (2) pending nested signals until system-call completion.
 + + + rt_sigprocmask(SIGUNBLOCK, SIGSEGV | SIGILL | SIGFPE | SIGBUS)
 ```
 
-### Async Signal Arrives During Enclave Code Execution
+#### Async Signal Arrives During Enclave Code Execution
 
 On the example of SIGINT, until we arrive into `_DkGenericSignalHandle()`.
 
@@ -158,7 +160,7 @@ On the example of SIGINT, until we arrive into `_DkGenericSignalHandle()`.
           < ... >
 ```
 
-### Async Signal Arrives During Non-Enclave Code Execution
+#### Async Signal Arrives During Non-Enclave Code Execution
 
 Non-enclave code execution can only happen if Graphene process is currently executing untrusted-PAL
 code, e.g., is blocked on a `futex(wait)` system call.
@@ -208,12 +210,12 @@ On the example of SIGINT, until we arrive into `_DkGenericSignalHandle()`.
             < ... >                                              v
 ```
 
-### Sync Signal Arrives During Enclave Code Execution
+#### Sync Signal Arrives During Enclave Code Execution
 
 This case is exactly the same as for async signal. The only difference in the diagram would be that
 `_DkTerminateSighandler` is replaced by `_DkResumeSighandler`. But the logic is exactly the same.
 
-### Sync Signal Arrives During Non-Enclave Code Execution
+#### Sync Signal Arrives During Non-Enclave Code Execution
 
 Non-enclave code execution can only happen if Graphene process is currently executing untrusted-PAL
 code, e.g., is blocked on a `futex(wait)` system call.
@@ -223,7 +225,7 @@ or arithmetic exception in untrusted-PAL code. This should never happen in a cor
 of Graphene. In this case, `_DkResumeSighandler` simply kills the faulting thread (not the whole
 process!) by issuing `exit(1)` syscall.
 
-### DkGenericSignalHandle Logic
+#### DkGenericSignalHandle Logic
 
 ```
   Normal context (enclave mode)
@@ -267,9 +269,9 @@ process!) by issuing `exit(1)` syscall.
 ```
 
 
-## Linux PAL Flows
+### Linux PAL Flows
 
-### Initialization of Signal Handling
+#### Initialization of Signal Handling
 
 Very similar to the flow for Linux-SGX. In addition to 7 handled signals, Linux PAL also operates on
 these signals:
@@ -278,7 +280,7 @@ these signals:
 
 Describing flows for these signals is *future work*.
 
-### Async Signal Arrives During PAL Call Execution
+#### Async Signal Arrives During PAL Call Execution
 
 ```
   Normal context                                Signal context
@@ -312,7 +314,7 @@ Describing flows for these signals is *future work*.
 + +     _DkGenericSignalHandle(event, NULL, NULL)
 ```
 
-### Async Signal Arrives During Non-PAL Call Execution
+#### Async Signal Arrives During Non-PAL Call Execution
 
 ```
   Normal context                                Signal context
@@ -338,7 +340,7 @@ Describing flows for these signals is *future work*.
 +
 ```
 
-### Sync Signal Arrives During PAL Call Execution
+#### Sync Signal Arrives During PAL Call Execution
 
 ```
   Normal context                                Signal context
@@ -361,7 +363,7 @@ Describing flows for these signals is *future work*.
 ... thread is dead ...
 ```
 
-### Sync Signal Arrives During Non-PAL Call Execution
+#### Sync Signal Arrives During Non-PAL Call Execution
 
 ```
   Normal context                                Signal context
@@ -387,7 +389,7 @@ Describing flows for these signals is *future work*.
 +
 ```
 
-### DkGenericSignalHandle Logic
+#### DkGenericSignalHandle Logic
 
 ```
   Normal context (enclave mode)
@@ -430,11 +432,11 @@ Describing flows for these signals is *future work*.
 ```
 
 
-## Current LibOS Flows
+### Current LibOS Flows
 
 Note that LibOS flows are the same for all PALs.
 
-### Non-Nested Signal Case
+#### Non-Nested Signal Case
 
 On the example of `suspend_upcall()`.
 
@@ -488,7 +490,7 @@ On the example of `suspend_upcall()`.
 + DkExceptionReturn(event)
 ```
 
-### Nested Signal Case
+#### Nested Signal Case
 
 On the example of `suspend_upcall()`. Assumes `tcb.context.preempt = 1` (in a signal handler).
 ```
@@ -544,7 +546,7 @@ On the example of `suspend_upcall()`. Assumes `tcb.context.preempt = 1` (in a si
 + + +     + < handles pended SIGINT from tcb.thread.signal_logs[SIGINT]
 ```
 
-### Available Signal Handlers and Their Differences
+#### Available Signal Handlers and Their Differences
 
 (Notation: <Linux signal> -> PAL signal -> LibOS signal handler (purpose))
 
@@ -647,7 +649,7 @@ illegal_upcall(event, context)
 ```
 
 
-# Alarm() Emulation
+## Alarm() Emulation
 
 SIGALRM signal is blocked in Graphene. Therefore, on `alarm()` syscall, SIGALRM is generated and
 raised purely by LibOS.
@@ -713,7 +715,7 @@ shim_do_alarm(seconds)                          ... no alive host thread ...
 ```
 
 
-# Bugs and Issues
+## Bugs and Issues
 
 * BUG? Graphene LibOS performs `DkThreadYieldExecution()` in `__handle_signal()` (i.e., yield
 thread execution after handling one pending signal). Looks useless.

Documentation/oldwiki/Supported-System-Calls-in-Graphene.md

@@ -1,3 +1,5 @@
+# Supported System Calls in Graphene
+
 The following is a list of system calls that are currently implemented.
 
 ## System Calls that are Fully Implemented