You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+31-19Lines changed: 31 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ Grates provide custom syscall wrappers for Lind cages. Each example grate here d
6
6
7
7
For more details on Lind and grates, refer to the official [documentation.](https://lind-project.github.io/lind-wasm/)
8
8
9
-
## Repository Structure
9
+
## Repository Structure
10
10
11
11
Each directory under `examples/` contains a standalone grate implementation.
12
12
@@ -15,19 +15,19 @@ For a grate written in `C`, the typical structure for an individual grate is:
15
15
```
16
16
examples/<name>-grate
17
17
├── src/ // .c and .h source files.
18
-
├── tests/ // Tests for this grate, run as child cages.
18
+
├── tests/ // Tests for this grate.
19
19
├── build.conf // Configuration file to describe additional build flags, `--max-memory` for wasm, and entry point for the grate.
20
-
├── compile_grate.sh // Compilation script that places the final *.wasm files in the `output/` folder.
21
-
└── README.md
20
+
├── compile_grate.sh // Compile script to generate *.wasm and *.cwasm binaries
21
+
└── README.md
22
22
```
23
23
24
24
## Writing a Grate
25
25
26
-
By default, syscalls called by a grate are redirected to `rawposix`. With grates, specific specific syscalls from a child cage can be redirected to custom handlers defined in the grate.
26
+
By default, syscalls invoked by a cage are forwarded to `rawposix`. A grate allows selected syscalls from a child cage to be intercepted and handled by custom functions.
27
27
28
-
Following the example in `examples/geteuid-grate`:
28
+
Using the example in `examples/geteuid-grate` to illustrate this process:
29
29
30
-
**Registering Syscalls:**
30
+
**Registering Syscall Handlers:**
31
31
32
32
First, define a custom implementation of the syscall.
33
33
@@ -40,25 +40,27 @@ int geteuid_grate(uint64_t cageid) {
40
40
Next, register this function as the handler for `geteuid` using the `register_handler` function
// Extract the function based on the function pointer that was passed.
76
-
// This is the same address that was passed to the register_handler function.
77
+
// Extract the function based on the function pointer that was passed.
78
+
// This is the same address that was passed to the register_handler function.
77
79
int (*fn)(uint64_t) = (int (*)(uint64_t))(uintptr_t)fn_ptr_uint;
78
80
79
81
// In this case, we only pass down the cageid as the argument for the geteuid syscall.
80
82
return fn(cageid);
81
83
}
82
84
```
83
85
86
+
**Process Coordination:**
87
+
88
+
Each grate must invoke `execv(argv[1], &argv[1])` exactly once, after registering its syscall handlers.
89
+
90
+
This design avoids centralized process coordination. Once `execv` is called, further process creation or handler registrations are the responsibility of the executed cage.
91
+
92
+
This also allows multiple grates to be interposed. For example:
Grates are compiled similarly to regular Lind programs, with the additional requirement that the `pass_fptr_to_wt` function must be an export of the WASM module.
99
+
Grates are compiled similarly to standard Lind programs, with the additional requirement that the WASM module exports the `pass_fptr_to_wt` function.
87
100
88
101
Example of a compile script: [`examples/geteuid-grate/compile_grate.sh`](./examples/geteuid-grate/compile_grate.sh)
89
102
90
103
## Running a Grate
91
104
92
-
Grates are run like regular lind programs, using the `lind_run` script.
93
-
94
-
By convention, a grate expects the child cage's command-line arguments to begin at `argv[1]`. The grate must execute the child cage using `execv(argv[1], &argv[1]`, thereby forwarding all remaining arguments to the cage unchanged.
105
+
Grates are executed like standard Lind programs, that expect cage binaries to be present at `argv[1]`.
0 commit comments