mirror of
https://github.com/phil-opp/blog_os.git
synced 2025-12-16 14:27:49 +00:00
Update some broken anchor links (#1444)
This commit is contained in:
Philipp Oppermann
committed by
GitHub
GitHub
parent
86c36479cf
commit
211f460251
@@ -151,7 +151,7 @@ Don't worry, you don't need to understand the details.
|
||||
### Long Mode check
|
||||
Now we can use CPUID to detect whether long mode can be used. I use code from [OSDev][long mode detection] again:
|
||||
|
||||
[long mode detection]: https://wiki.osdev.org/Setting_Up_Long_Mode#x86_or_x86-64
|
||||
[long mode detection]: wiki.osdev.org/Setting_Up_Long_Mode#Checking_for_long_mode_support
|
||||
|
||||
```nasm
|
||||
check_long_mode:
|
||||
@@ -173,7 +173,7 @@ check_long_mode:
|
||||
```
|
||||
Like many low-level things, CPUID is a bit strange. Instead of taking a parameter, the `cpuid` instruction implicitly uses the `eax` register as argument. To test if long mode is available, we need to call `cpuid` with `0x80000001` in `eax`. This loads some information to the `ecx` and `edx` registers. Long mode is supported if the 29th bit in `edx` is set. [Wikipedia][cpuid long mode] has detailed information.
|
||||
|
||||
[cpuid long mode]: https://en.wikipedia.org/wiki/CPUID#EAX.3D80000001h:_Extended_Processor_Info_and_Feature_Bits
|
||||
[cpuid long mode]: https://en.wikipedia.org/wiki/CPUID#EAX=8000'0001h:_Extended_Processor_Info_and_Feature_Bits
|
||||
|
||||
If you look at the assembly above, you'll probably notice that we call `cpuid` twice. The reason is that the CPUID command started with only a few functions and was extended over time. So old processors may not know the `0x80000001` argument at all. To test if they do, we need to invoke `cpuid` with `0x80000000` in `eax` first. It returns the highest supported parameter value in `eax`. If it's at least `0x80000001`, we can test for long mode as described above. Else the CPU is old and doesn't know what long mode is either. In that case, we directly jump to `.no_long_mode` through the `jb` instruction (“jump if below”).
|
||||
|
||||
@@ -229,20 +229,20 @@ But what happens to bits 48-63 of the 64-bit virtual address? Well, they can't b
|
||||
|
||||
An entry in the P4, P3, P2, and P1 tables consists of the page aligned 52-bit _physical_ address of the frame or the next page table and the following bits that can be OR-ed in:
|
||||
|
||||
Bit(s) | Name | Meaning
|
||||
--------------------- | ------ | ----------------------------------
|
||||
0 | present | the page is currently in memory
|
||||
1 | writable | it's allowed to write to this page
|
||||
2 | user accessible | if not set, only kernel mode code can access this page
|
||||
3 | write through caching | writes go directly to memory
|
||||
4 | disable cache | no cache is used for this page
|
||||
5 | accessed | the CPU sets this bit when this page is used
|
||||
6 | dirty | the CPU sets this bit when a write to this page occurs
|
||||
7 | huge page/null | must be 0 in P1 and P4, creates a 1GiB page in P3, creates a 2MiB page in P2
|
||||
8 | global | page isn't flushed from caches on address space switch (PGE bit of CR4 register must be set)
|
||||
9-11 | available | can be used freely by the OS
|
||||
52-62 | available | can be used freely by the OS
|
||||
63 | no execute | forbid executing code on this page (the NXE bit in the EFER register must be set)
|
||||
| Bit(s) | Name | Meaning |
|
||||
| ------ | --------------------- | -------------------------------------------------------------------------------------------- |
|
||||
| 0 | present | the page is currently in memory |
|
||||
| 1 | writable | it's allowed to write to this page |
|
||||
| 2 | user accessible | if not set, only kernel mode code can access this page |
|
||||
| 3 | write through caching | writes go directly to memory |
|
||||
| 4 | disable cache | no cache is used for this page |
|
||||
| 5 | accessed | the CPU sets this bit when this page is used |
|
||||
| 6 | dirty | the CPU sets this bit when a write to this page occurs |
|
||||
| 7 | huge page/null | must be 0 in P1 and P4, creates a 1GiB page in P3, creates a 2MiB page in P2 |
|
||||
| 8 | global | page isn't flushed from caches on address space switch (PGE bit of CR4 register must be set) |
|
||||
| 9-11 | available | can be used freely by the OS |
|
||||
| 52-62 | available | can be used freely by the OS |
|
||||
| 63 | no execute | forbid executing code on this page (the NXE bit in the EFER register must be set) |
|
||||
|
||||
### Set Up Identity Paging
|
||||
When we switch to long mode, paging will be activated automatically. The CPU will then try to read the instruction at the following address, but this address is now a virtual address. So we need to do _identity mapping_, i.e. map a physical address to the same virtual address.
|
||||
@@ -387,18 +387,18 @@ Today almost everyone uses Paging instead of Segmentation (and so do we). But on
|
||||
|
||||
A GDT always starts with a 0-entry and contains an arbitrary number of segment entries afterwards. A 64-bit entry has the following format:
|
||||
|
||||
Bit(s) | Name | Meaning
|
||||
--------------------- | ------ | ----------------------------------
|
||||
0-41 | ignored | ignored in 64-bit mode
|
||||
42 | conforming | the current privilege level can be higher than the specified level for code segments (else it must match exactly)
|
||||
43 | executable | if set, it's a code segment, else it's a data segment
|
||||
44 | descriptor type | should be 1 for code and data segments
|
||||
45-46 | privilege | the [ring level]: 0 for kernel, 3 for user
|
||||
47 | present | must be 1 for valid selectors
|
||||
48-52 | ignored | ignored in 64-bit mode
|
||||
53 | 64-bit | should be set for 64-bit code segments
|
||||
54 | 32-bit | must be 0 for 64-bit segments
|
||||
55-63 | ignored | ignored in 64-bit mode
|
||||
| Bit(s) | Name | Meaning |
|
||||
| ------ | --------------- | ----------------------------------------------------------------------------------------------------------------- |
|
||||
| 0-41 | ignored | ignored in 64-bit mode |
|
||||
| 42 | conforming | the current privilege level can be higher than the specified level for code segments (else it must match exactly) |
|
||||
| 43 | executable | if set, it's a code segment, else it's a data segment |
|
||||
| 44 | descriptor type | should be 1 for code and data segments |
|
||||
| 45-46 | privilege | the [ring level]: 0 for kernel, 3 for user |
|
||||
| 47 | present | must be 1 for valid selectors |
|
||||
| 48-52 | ignored | ignored in 64-bit mode |
|
||||
| 53 | 64-bit | should be set for 64-bit code segments |
|
||||
| 54 | 32-bit | must be 0 for 64-bit segments |
|
||||
| 55-63 | ignored | ignored in 64-bit mode |
|
||||
|
||||
[ring level]: https://wiki.osdev.org/Security#Rings
|
||||
|
||||
|
||||
@@ -26,25 +26,25 @@ This post uses recent unstable features, so you need an up-to-date nighly compil
|
||||
## The VGA Text Buffer
|
||||
The text buffer starts at physical address `0xb8000` and contains the characters displayed on screen. It has 25 rows and 80 columns. Each screen character has the following format:
|
||||
|
||||
Bit(s) | Value
|
||||
------ | ----------------
|
||||
0-7 | ASCII code point
|
||||
8-11 | Foreground color
|
||||
12-14 | Background color
|
||||
15 | Blink
|
||||
| Bit(s) | Value |
|
||||
| ------ | ---------------- |
|
||||
| 0-7 | ASCII code point |
|
||||
| 8-11 | Foreground color |
|
||||
| 12-14 | Background color |
|
||||
| 15 | Blink |
|
||||
|
||||
The following colors are available:
|
||||
|
||||
Number | Color | Number + Bright Bit | Bright Color
|
||||
------ | ---------- | ------------------- | -------------
|
||||
0x0 | Black | 0x8 | Dark Gray
|
||||
0x1 | Blue | 0x9 | Light Blue
|
||||
0x2 | Green | 0xa | Light Green
|
||||
0x3 | Cyan | 0xb | Light Cyan
|
||||
0x4 | Red | 0xc | Light Red
|
||||
0x5 | Magenta | 0xd | Pink
|
||||
0x6 | Brown | 0xe | Yellow
|
||||
0x7 | Light Gray | 0xf | White
|
||||
| Number | Color | Number + Bright Bit | Bright Color |
|
||||
| ------ | ---------- | ------------------- | ------------ |
|
||||
| 0x0 | Black | 0x8 | Dark Gray |
|
||||
| 0x1 | Blue | 0x9 | Light Blue |
|
||||
| 0x2 | Green | 0xa | Light Green |
|
||||
| 0x3 | Cyan | 0xb | Light Cyan |
|
||||
| 0x4 | Red | 0xc | Light Red |
|
||||
| 0x5 | Magenta | 0xd | Pink |
|
||||
| 0x6 | Brown | 0xe | Yellow |
|
||||
| 0x7 | Light Gray | 0xf | White |
|
||||
|
||||
Bit 4 is the _bright bit_, which turns for example blue into light blue. It is unavailable in background color as the bit is used to control if the text should blink. If you want to use a light background color (e.g. white) you have to disable blinking through a [BIOS function][disable blinking].
|
||||
|
||||
@@ -441,7 +441,7 @@ But we can't use it to print anything! You can try it yourself in the `print_som
|
||||
|
||||
To resolve it, we could use a [mutable static]. But then every read and write to it would be unsafe since it could easily introduce data races and other bad things. Using `static mut` is highly discouraged, there are even proposals to [remove it][remove static mut].
|
||||
|
||||
[mutable static]: https://doc.rust-lang.org/1.30.0/book/second-edition/ch19-01-unsafe-rust.html#accessing-or-modifying-a-mutable-static-variable
|
||||
[mutable static]: https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html#accessing-or-modifying-a-mutable-static-variable
|
||||
[remove static mut]: https://internals.rust-lang.org/t/pre-rfc-remove-static-mut/1437
|
||||
|
||||
But what are the alternatives? We could try to use a cell type like [RefCell] or even [UnsafeCell] to provide [interior mutability]. But these types aren't [Sync] \(with good reason), so we can't use them in statics.
|
||||
|
||||
@@ -35,26 +35,26 @@ For the full list of exceptions check out the [OSDev wiki][exceptions].
|
||||
### The Interrupt Descriptor Table
|
||||
In order to catch and handle exceptions, we have to set up a so-called _Interrupt Descriptor Table_ (IDT). In this table we can specify a handler function for each CPU exception. The hardware uses this table directly, so we need to follow a predefined format. Each entry must have the following 16-byte structure:
|
||||
|
||||
Type| Name | Description
|
||||
----|--------------------------|-----------------------------------
|
||||
u16 | Function Pointer [0:15] | The lower bits of the pointer to the handler function.
|
||||
u16 | GDT selector | Selector of a code segment in the GDT.
|
||||
u16 | Options | (see below)
|
||||
u16 | Function Pointer [16:31] | The middle bits of the pointer to the handler function.
|
||||
u32 | Function Pointer [32:63] | The remaining bits of the pointer to the handler function.
|
||||
u32 | Reserved |
|
||||
| Type | Name | Description |
|
||||
| ---- | ------------------------ | ---------------------------------------------------------- |
|
||||
| u16 | Function Pointer [0:15] | The lower bits of the pointer to the handler function. |
|
||||
| u16 | GDT selector | Selector of a code segment in the GDT. |
|
||||
| u16 | Options | (see below) |
|
||||
| u16 | Function Pointer [16:31] | The middle bits of the pointer to the handler function. |
|
||||
| u32 | Function Pointer [32:63] | The remaining bits of the pointer to the handler function. |
|
||||
| u32 | Reserved |
|
||||
|
||||
The options field has the following format:
|
||||
|
||||
Bits | Name | Description
|
||||
------|-----------------------------------|-----------------------------------
|
||||
0-2 | Interrupt Stack Table Index | 0: Don't switch stacks, 1-7: Switch to the n-th stack in the Interrupt Stack Table when this handler is called.
|
||||
3-7 | Reserved |
|
||||
8 | 0: Interrupt Gate, 1: Trap Gate | If this bit is 0, interrupts are disabled when this handler is called.
|
||||
9-11 | must be one |
|
||||
12 | must be zero |
|
||||
13‑14 | Descriptor Privilege Level (DPL) | The minimal privilege level required for calling this handler.
|
||||
15 | Present |
|
||||
| Bits | Name | Description |
|
||||
| ----- | -------------------------------- | --------------------------------------------------------------------------------------------------------------- |
|
||||
| 0-2 | Interrupt Stack Table Index | 0: Don't switch stacks, 1-7: Switch to the n-th stack in the Interrupt Stack Table when this handler is called. |
|
||||
| 3-7 | Reserved |
|
||||
| 8 | 0: Interrupt Gate, 1: Trap Gate | If this bit is 0, interrupts are disabled when this handler is called. |
|
||||
| 9-11 | must be one |
|
||||
| 12 | must be zero |
|
||||
| 13‑14 | Descriptor Privilege Level (DPL) | The minimal privilege level required for calling this handler. |
|
||||
| 15 | Present |
|
||||
|
||||
Each exception has a predefined IDT index. For example the invalid opcode exception has table index 6 and the page fault exception has table index 14. Thus, the hardware can automatically load the corresponding IDT entry for each exception. The [Exception Table][exceptions] in the OSDev wiki shows the IDT indexes of all exceptions in the “Vector nr.” column.
|
||||
|
||||
@@ -147,10 +147,10 @@ In contrast, a called function is allowed to overwrite _scratch_ registers witho
|
||||
|
||||
On x86_64, the C calling convention specifies the following preserved and scratch registers:
|
||||
|
||||
preserved registers | scratch registers
|
||||
---|---
|
||||
`rbp`, `rbx`, `rsp`, `r12`, `r13`, `r14`, `r15` | `rax`, `rcx`, `rdx`, `rsi`, `rdi`, `r8`, `r9`, `r10`, `r11`
|
||||
_callee-saved_ | _caller-saved_
|
||||
| preserved registers | scratch registers |
|
||||
| ----------------------------------------------- | ----------------------------------------------------------- |
|
||||
| `rbp`, `rbx`, `rsp`, `r12`, `r13`, `r14`, `r15` | `rax`, `rcx`, `rdx`, `rsi`, `rdi`, `r8`, `r9`, `r10`, `r11` |
|
||||
| _callee-saved_ | _caller-saved_ |
|
||||
|
||||
The compiler knows these rules, so it generates the code accordingly. For example, most functions begin with a `push rbp`, which backups `rbp` on the stack (because it's a callee-saved register).
|
||||
|
||||
@@ -317,7 +317,7 @@ pub fn init() {
|
||||
There are two problems with this. First, statics are immutable, so we can't modify the breakpoint entry from our `init` function. Second, the `Idt::new` function is not a [`const` function], so it can't be used to initialize a `static`. We could solve this problem by using a [`static mut`] of type `Option<Idt>`:
|
||||
|
||||
[`const` function]: https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md
|
||||
[`static mut`]: https://doc.rust-lang.org/1.30.0/book/second-edition/ch19-01-unsafe-rust.html#accessing-or-modifying-a-mutable-static-variable
|
||||
[`static mut`]: https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html#accessing-or-modifying-a-mutable-static-variable
|
||||
|
||||
```rust
|
||||
static mut IDT: Option<Idt> = None;
|
||||
|
||||
Reference in New Issue
Block a user