Skip to content

Commit 51e4d53

Browse files
committed
added scheduler task
1 parent 110645f commit 51e4d53

File tree

1 file changed

+40
-0
lines changed

1 file changed

+40
-0
lines changed

docs/embedded/index.md

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -162,3 +162,43 @@ fn allocate_grant(&self, process_id: kernel::ProcessId) -> Result<(), kernel::pr
162162
For the command logic, you must also use the `enter` API. The first parameter of the closure will be a mutable reference to a `GrantData` wrapper over the previously defined `App`. The wrapper is transparent, meaning it permits accessing fields of the generic type.
163163

164164
The next step is configuring the capsule in the board's main file. Remember you need to add the capsule in the `NucleoF429ZI` structure, the `SyscallDriverLookup` and initialize the printer counter capsule.
165+
166+
## The role of a Scheduler
167+
168+
This task aims to illustrate the importance of OS preemption in the context of untrusted applications. Currently the scheduler used by the board is `kernel::scheduler::RoundRobinSched`, which implements a classical scheduling algorithm, allowing each process to run up to a maximum time slice called **quanta**. In the event that an application tries starving all other processes, the kernel will interrupt the malicious application after its quanta expires and will then schedule another process.
169+
170+
### Trust but verify
171+
172+
Your task will be to verify the previous claims, by flashing two C applications. One of them will be the `blink` example. After flashing the kernel by running `make flash` in the board's main directory (`boards/nucleo_f429zi`), you can load the application by running `make flash` in the example's root folder (`example/blink`).
173+
174+
As there are no *"malicious"* examples, we will have to add them on our own. In this case, an app that would print a message, then just infinitely spin in a `while` loop is enough. For this, you can adapt the `examples/c_hello` example, the flash it.
175+
176+
If you managed to flash both applications, you should be able to connect to the board using `tockloader listen` and see a similar output when running `list`:
177+
178+
```shell
179+
tockloader listen
180+
[INFO ] No device name specified. Using default name "tock".
181+
[INFO ] No serial port with device name "tock" found.
182+
[INFO ] Found 2 serial ports.
183+
Multiple serial port options found. Which would you like to use?
184+
[0] /dev/cu.debug-console - n/a
185+
[1] /dev/cu.usbmodem1103 - STM32 STLink
186+
187+
Which option? [0] 1
188+
[INFO ] Using "/dev/cu.usbmodem1103 - STM32 STLink".
189+
[INFO ] Listening for serial output.
190+
191+
tock$ list
192+
PID ShortID Name Quanta Syscalls Restarts Grants State
193+
0 Unique blink 0 289 0 1/11 Yielded
194+
1 Unique ws-demo 640 6 0 1/11 Running
195+
tock$
196+
```
197+
198+
You should be able to see the on-board LEDs flashing on the board.
199+
200+
### Cooperation flaw
201+
202+
Now, let's test the same scenario, but with a cooperative scheduling mechanism. You have to first change the kernel's scheduler in the board's `main.rs` file to use the `scheduler::cooperative::CooperativeSched`. Then you must re-flash the kernel by running `make flash`. Fortunately flashing the kernel should preserve the applications, so you will not have to re-flash them as well.
203+
204+
After you are done flashing, check that both applications are present. You can try to reset the board a few times by running `reset` in tock's process console (the terminal you open by running `tockloader listen`).

0 commit comments

Comments
 (0)