A double fault behaves like a normal exception. It has the vector number `8` and we can define a normal handler function for it in the IDT. It is really important to provide a double fault handler, because if a double faults is unhandled a fatal _triple fault_ occurs. Triple faults can't be caught and most hardware reacts with a system reset.
A double fault behaves like a normal exception. It has the vector number `8` and we can define a normal handler function for it in the IDT. It is really important to provide a double fault handler, because if a double fault is unhandled a fatal _triple fault_ occurs. Triple faults can't be caught and most hardware reacts with a system reset.
### Triggering a Double Fault
Let's provoke a double fault by triggering an exception for that we didn't define a handler function yet:
@@ -189,7 +189,9 @@ When we try this code in QEMU, we see that the system enters a boot-loop again.
So how can we avoid this problem? We can't omit the pushing of the exception stack frame, since the CPU itself does it. So we need to ensure somehow that the stack is always valid when a double fault exception occurs. Fortunately, the x86_64 architecture has a solution to this problem.
## Switching Stacks
The x86_64 architecture is able to switch to a predefined stack for some exceptions through an _Interrupt Stack Table_ (IST). The IST is a table of 7 pointers to known-good stacks. In Rust-like pseudo code:
The x86_64 architecture is able to switch to a predefined, known-good stack when an exception occurs. This switch happens at hardware level, so it can be performed before the CPU pushes the exception stack frame.
This switching mechanism is implemented as an _Interrupt Stack Table_ (IST). The IST is a table of 7 pointers to known-good stacks. In Rust-like pseudo code:
For each exception handler, we can choose an IST stack through the options field in the [IDT entry]. For example, we could use the first stack in the IST for our double fault handler. Then the CPU would automatically switch to this stack _before_ it pushes anything. Thus, we are able to avoid the triple fault.
For each exception handler, we can choose an stack from the IST through the `options` field in the corresponding [Interrupt Descriptor Table entry]. For example, we could use the first stack in the IST for our double fault handler. Then the CPU would automatically switch to this stack whenever a double fault occurs. This switch would happen before anything is pushed, so it would prevent the triple fault.
In order to fill an Interrupt Stack Table later, we need a way to allocate new stacks. Therefore we extend our `memory` module with a new `stack_allocator` submodule:
```rust
// in src/memory/mod.rs
modstack_allocator;
```
#### The `stack_allocator` Module
First, we create a new `StackAllocator` struct and a constructor function:
```rust
// in src/memory/stack_allocator.rs
usememory::paging::PageIter;
pubstructStackAllocator{
range: PageIter,
}
implStackAllocator{
pubfnnew(page_range: PageIter)-> StackAllocator{
StackAllocator{range: page_range}
}
}
```
We create a simple `StackAllocator` that allocates stacks from a given range of pages (`PageIter` is an Iterator over a range of pages; we introduced it [in the kernel heap post].).
TODO: Instead of adding a `StackAllocator::new` function, we use a separate `new_stack_allocator` function. This way, we can re-export `StackAllocator` from the `memory` module without re-exporting the `new` function.
[in the kernel heap post]: {{% relref "08-kernel-heap.md#mapping-the-heap" %}}
In order to allocate new stacks, we add a `alloc_stack` method:
```rust
// in src/memory/stack_allocator.rs
usememory::paging::{self,Page,ActivePageTable};
usememory::{PAGE_SIZE,FrameAllocator};
implStackAllocator{
pubfnalloc_stack<FA: FrameAllocator>(&mutself,
active_table: &mutActivePageTable,
frame_allocator: &mutFA,
size_in_pages: usize)
-> Option<Stack>{
ifsize_in_pages==0{
returnNone;/* a zero sized stack makes no sense */
}
// clone the range, since we only want to change it on success
letmutrange=self.range.clone();
// try to allocate the stack pages and a guard page
letguard_page=range.next();
letstack_start=range.next();
letstack_end=ifsize_in_pages==1{
stack_start
}else{
// choose the (size_in_pages-2)th element, since index
// starts at 0 and we already allocated the start page
The method takes mutable references to the [ActivePageTable] and a [FrameAllocator], since it needs to map the new virtual stack pages to physical frames. The stack size is a multiple of the page size.
Instead of operating directly on `self.range`, we [clone] it and only write it back on success. This way, subsequent stack allocations can still succeed if there are pages left. For example, a call with `size_in_pages = 3` can still succeed after a failed call with `size_in_pages = 100`. In order to be able to clone `PageIter`, we add a `#[derive(Clone)]` to its definition in `src/memory/paging/mod.rs`.
The actual allocation is straightforward: First, we choose the next page as [guard page]. Then we choose the next `size_in_pages` pages as stack pages using [Iterator::nth]. If all three variables are `Some`, the allocation succeeded and we map the stack pages to physical frames using [ActivePageTable::map]. The guard page remains unmapped.
Finally, we create and return a new `Stack`, which is defined as follows:
```rust
// in src/memory/stack_allocator.rs
#[derive(Debug)]
pubstructStack{
top: StackPointer,
bottom: StackPointer,
}
implStack{
fnnew(top: usize,bottom: usize)-> Stack{
assert!(top>bottom);
Stack{
top: StackPointer::new(top),
bottom: StackPointer::new(bottom),
}
}
pubfntop(&self)-> StackPointer{
self.top
}
}
usecore::nonzero::NonZero;
#[derive(Debug, Clone, Copy)]
pubstructStackPointer(NonZero<usize>);
implStackPointer{
fnnew(ptr: usize)-> StackPointer{
assert!(ptr!=0);
StackPointer(unsafe{NonZero::new(ptr)})
}
}
implInto<usize>forStackPointer{
fninto(self)-> usize{
*self.0
}
}
```
The `Stack` struct describes a stack though its top and bottom pointers. A stack pointer can never be `0`, so we use the unstable [NonZero] wrapper for `StackPointer`. This wrapper is an optimization that tells the compiler that it can use the value `0` to differentiate enum variants. Thus, an `Option<StackPointer>` has always the same size as a bare `usize` (the value `0` is used to store the `None` case). We will require this property when we create the Interrupt Stack Table later.
Since `NonZero` is unstable, we need to add `#![feature(nonzero)]` in our `lib.rs`.
Now we're already able to allocate a new double fault stack. However, we add one more level of abstraction to make things nicer. For that we add a `MemoryController` type to our `memory` module:
The `MemoryController` struct holds the three types that are required for `alloc_stack` and provides a simpler interface (only one argument). The `alloc_stack` wrapper just takes the tree types as `&mut` through [destructuring] and forwards them to the `stack_allocator`. Note that we're re-exporting the `Stack` and `StackPointer` types since they are returned by `alloc_stack`.
The last step is to create a `stack_allocator` and return a `MemoryController` from `memory::init`:
let double_fault_stack = memory_controller.alloc_stack(1)
.expect("could not allocate double fault stack");
IDT.load();
}
{{< / highlight >}}
We allocate a 4096 bytes stack (one page) for our double fault handler. Now we just need some way to tell the CPU that it should use this stack for handling double faults.
### The IST and TSS
The Interrupt Stack Table (IST) is part of an old legacy structure called [Task State Segment] (TSS). The TSS used to hold various information (e.g. processor register state) about a task in 32-bit x86 and was for example used for [hardware context switching]. However, hardware context switching is no longer supported in 64-bit mode and the format of the TSS changed completely.
[Task State Segment]: https://en.wikipedia.org/wiki/Task_state_segment
The _Privilege Stack Table_ is used by the CPU when the privilege level changes. For example, if an exception occurs while the CPU is in user mode (privilege level 3), the CPU normally switches to kernel mode (privilege level 0) before invoking the exception handler. In that case, the CPU would switch to the 0th stack in the Privilege Stack Table (since 0 is the target privilege level). We don't have any user mode programs yet, so we can safely ignore this table for now.
The _Privilege Stack Table_ is used by the CPU when the privilege level changes. For example, if an exception occurs while the CPU is in user mode (privilege level 3), the CPU normally switches to kernel mode (privilege level 0) before invoking the exception handler. In that case, the CPU would switch to the 0th stack in the Privilege Stack Table (since 0 is the target privilege level). We don't have any user mode programs yet, so we ignore this table for now.
Let's create a `TaskStateSegment` struct in new tss submodule:
Let's create a `TaskStateSegment` struct in a new `tss` submodule:
We use [repr\(C)] for the struct since the order is fields is important. We also use `[repr(packed)]` because otherwise the compiler might insert additional padding between the `reserved_0` and `privilege_stacks` fields.
The `PrivilegeStackTable` and `InterruptStackTable` types are just newtype wrappers for arrays of `Option<StackPointer>`. Here it becomes important that we implemented `NonZero` for `StackPointer`: Thus, an `Option<StackPointer>` still has the required size of 64 bits.
However, it is a bit cumbersome to setup this mechanism.
Let's add a `TaskStateSegment::new` function that creates an empty TSS:
The mechanism consists of two main components: An _Interrupt Stack Table_ and a _Task State Segment_.
The function iterates over the table and places the stack pointer in the first free entry. In the case of success, we return the table index of the inserted pointer. If there's no free entry left, we return the stack back to the caller as `Err`.
#### Creating a TSS
Let's build a new TSS that contains our double fault stack in its Interrupt Stack Table.
Switching stacks
The Interrupt Stack Table
The Task State Segment
The Global Descriptor Table (again)
Putting it together
What’s next?
@@ -282,11 +554,3 @@ Let's start by creating a handler function for double faults:
```
Next, we need to register the double fault handler in our IDT:
Double faults also occur when an exception occurs while the CPU is trying to invoke an exception handler. For example, let's assume a divide-by-zero exception occurs but the OS accidentally [swapped out] the corresponding handler function. Now the CPU tries to call the divide-by-zero handler, which
A double fault occurs whenever the CPU fails to call an exception handler. On a high level it's like a catch-all handler, similar to `catch(...)` in C++ or `catch(Exception e)` in Java or C#.
The most common case is that there isn't a handler defined in the IDT. However, a double fault also occurs if the exception handler lies on a unaccessible page of if the CPU fails to push the exception stack frame.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Philipp Oppermann