diff --git a/blog/post/2015-08-18-multiboot-kernel.md b/blog/post/2015-08-18-multiboot-kernel.md index fafdf2f1..3fe961cf 100644 --- a/blog/post/2015-08-18-multiboot-kernel.md +++ b/blog/post/2015-08-18-multiboot-kernel.md @@ -183,11 +183,11 @@ We can use `objdump` to print the sections of the generated executable and verif kernel.bin: file format elf64-x86-64 Sections: -Idx Name Size VMA LMA File off Algn - 0 .boot 00000018 0000000000100000 0000000000100000 00000080 2**0 - CONTENTS, ALLOC, LOAD, READONLY, DATA - 1 .text 0000000b 0000000000100020 0000000000100020 000000a0 2**4 - CONTENTS, ALLOC, LOAD, READONLY, CODE +Idx Name Size VMA LMA File off Algn + 0 .boot 00000018 0000000000100000 0000000000100000 00000080 2**0 + CONTENTS, ALLOC, LOAD, READONLY, DATA + 1 .text 0000000b 0000000000100020 0000000000100020 000000a0 2**4 + CONTENTS, ALLOC, LOAD, READONLY, CODE ``` _Note_: The `ld` and `objdump` commands are platform specific. If you're _not_ working on x86_64 architecture, you will need to [cross compile binutils]. Then use `x86_64‑elf‑ld` and `x86_64‑elf‑objdump` instead of `ld` and `objdump`. [cross compile binutils]: {{% relref "cross-compile-binutils.md" %}} @@ -265,7 +265,7 @@ Right now we need to execute 4 commands in the right order everytime we change a ├── linker.ld └── grub.cfg ``` -The Makefile looks like this (but indented with tabs instead of spaces): +The Makefile looks like this (indented with tabs instead of spaces): ```Makefile arch ?= x86_64 @@ -276,34 +276,34 @@ linker_script := src/arch/$(arch)/linker.ld grub_cfg := src/arch/$(arch)/grub.cfg assembly_source_files := $(wildcard src/arch/$(arch)/*.asm) assembly_object_files := $(patsubst src/arch/$(arch)/%.asm, \ - build/arch/$(arch)/%.o, $(assembly_source_files)) + build/arch/$(arch)/%.o, $(assembly_source_files)) .PHONY: all clean run iso all: $(kernel) clean: - @rm -r build + @rm -r build run: $(iso) - @qemu-system-x86_64 -cdrom $(iso) + @qemu-system-x86_64 -cdrom $(iso) iso: $(iso) $(iso): $(kernel) $(grub_cfg) - @mkdir -p build/isofiles/boot/grub - @cp $(kernel) build/isofiles/boot/kernel.bin - @cp $(grub_cfg) build/isofiles/boot/grub - @grub-mkrescue -o $(iso) build/isofiles 2> /dev/null - @rm -r build/isofiles + @mkdir -p build/isofiles/boot/grub + @cp $(kernel) build/isofiles/boot/kernel.bin + @cp $(grub_cfg) build/isofiles/boot/grub + @grub-mkrescue -o $(iso) build/isofiles 2> /dev/null + @rm -r build/isofiles $(kernel): $(assembly_object_files) $(linker_script) - @ld -n -T $(linker_script) -o $(kernel) $(assembly_object_files) + @ld -n -T $(linker_script) -o $(kernel) $(assembly_object_files) # compile assembly files build/arch/$(arch)/%.o: src/arch/$(arch)/%.asm - @mkdir -p $(shell dirname $@) - @nasm -felf64 $< -o $@ + @mkdir -p $(shell dirname $@) + @nasm -felf64 $< -o $@ ``` Some comments (see the [Makefile tutorial] if you don't know `make`): diff --git a/blog/post/2015-08-25-entering-longmode.md b/blog/post/2015-08-25-entering-longmode.md index fda8ffac..761439fd 100644 --- a/blog/post/2015-08-25-entering-longmode.md +++ b/blog/post/2015-08-25-entering-longmode.md @@ -109,8 +109,8 @@ In `no_multiboot`, we use the `jmp` (“jump”) instruction to jump to our erro ```nasm check_cpuid: - ; Check if CPUID is supported by attempting to flip the ID bit (bit 21) in - ; the FLAGS register. If we can flip it, CPUID is available. + ; Check if CPUID is supported by attempting to flip the ID bit (bit 21) + ; in the FLAGS register. If we can flip it, CPUID is available. ; Copy FLAGS in to EAX via stack pushfd @@ -130,13 +130,13 @@ check_cpuid: pushfd pop eax - ; Restore FLAGS from the old version stored in ECX (i.e. flipping the ID bit - ; back if it was ever flipped). + ; Restore FLAGS from the old version stored in ECX (i.e. flipping the + ; ID bit back if it was ever flipped). push ecx popfd - ; Compare EAX and ECX. If they are equal then that means the bit wasn't - ; flipped, and CPUID isn't supported. + ; Compare EAX and ECX. If they are equal then that means the bit + ; wasn't flipped, and CPUID isn't supported. cmp eax, ecx je .no_cpuid ret diff --git a/blog/post/2015-09-02-set-up-rust.md b/blog/post/2015-09-02-set-up-rust.md index a4d71199..1c38dcaf 100644 --- a/blog/post/2015-09-02-set-up-rust.md +++ b/blog/post/2015-09-02-set-up-rust.md @@ -92,7 +92,8 @@ target ?= $(arch)-unknown-linux-gnu rust_os := target/$(target)/debug/libblog_os.a # ... $(kernel): cargo $(rust_os) $(assembly_object_files) $(linker_script) - @ld -n -T $(linker_script) -o $(kernel) $(assembly_object_files) $(rust_os) + @ld -n -T $(linker_script) -o $(kernel) \ + $(assembly_object_files) $(rust_os) cargo: @cargo build --target $(target) @@ -155,10 +156,14 @@ pub extern fn rust_main() { Now `make run` doesn't complain about `memcpy` anymore. Instead it will show a pile of new errors: ``` -target/debug/libblog_os.a(core-35017696.0.o): In function `ops::f32.Rem::rem::hfcbbcbe5711a6e6emxm': -core.0.rs:(.text._ZN3ops7f32.Rem3rem20hfcbbcbe5711a6e6emxmE+0x1): undefined reference to `fmodf' -target/debug/libblog_os.a(core-35017696.0.o): In function `ops::f64.Rem::rem::hbf225030671c7a35Txm': -core.0.rs:(.text._ZN3ops7f64.Rem3rem20hbf225030671c7a35TxmE+0x1): undefined reference to `fmod' +target/debug/libblog_os.a(core-35017696.0.o): + In function `ops::f32.Rem::rem::hfcbbcbe5711a6e6emxm': + core.0.rs:(.text._ZN3ops7f32.Rem3rem20hfcbbcbe5711a6e6emxmE+0x1): + undefined reference to `fmodf' +target/debug/libblog_os.a(core-35017696.0.o): + In function `ops::f64.Rem::rem::hbf225030671c7a35Txm': + core.0.rs:(.text._ZN3ops7f64.Rem3rem20hbf225030671c7a35TxmE+0x1): + undefined reference to `fmod' ... ``` @@ -176,7 +181,8 @@ So how do we fix this problem? We don't use any floating point operations, so we ```make $(kernel): cargo $(rust_os) $(assembly_object_files) $(linker_script) - @ld -n --gc-sections -T $(linker_script) -o $(kernel) $(assembly_object_files) $(rust_os) + @ld -n --gc-sections -T $(linker_script) -o $(kernel) \ + $(assembly_object_files) $(rust_os) ``` Now we can do a `make run` again and… it doesn't boot anymore: @@ -205,8 +211,12 @@ The following snippet still fails: The error is a linker error again (hence the ugly error message): ``` -target/debug/libblog_os.a(blog_os.0.o): In function `blog_os::iter::Iterator::zip, core::ops::Range, closure>,core::ops::RangeFrom>': -/home/.../src/libcore/iter.rs:654: undefined reference to `_Unwind_Resume' +target/debug/libblog_os.a(blog_os.0.o): + In function `blog_os::iter::Iterator::zip, core::ops::Range, closure>, + core::ops::RangeFrom>': + /home/.../src/libcore/iter.rs:654: + undefined reference to `_Unwind_Resume' ``` So the linker can't find a function named `_Unwind_Resume` that is referenced in `iter.rs:654` in libcore. This reference is not really there at [line 654 of libcore's `iter.rs`][iter.rs:654]. Instead, it is a compiler inserted _landing pad_, which is used for exception handling. @@ -214,7 +224,7 @@ The easiest way of fixing this problem is to disable the landing pad creation si ```make cargo: - @cargo rustc --target $(target) -- -Z no-landing-pads + @cargo rustc --target $(target) -- -Z no-landing-pads ``` Now we fixed all linking issues. diff --git a/blog/post/2015-10-23-printing-to-screen.md b/blog/post/2015-10-23-printing-to-screen.md index 019b667c..b884a14c 100644 --- a/blog/post/2015-10-23-printing-to-screen.md +++ b/blog/post/2015-10-23-printing-to-screen.md @@ -384,7 +384,7 @@ Rust's [macro syntax] is a bit strange, so we won't try to write a macro from sc [macro syntax]: https://doc.rust-lang.org/nightly/book/macros.html [`println!` macro]: https://doc.rust-lang.org/nightly/std/macro.println!.html -``` +```rust macro_rules! println { ($fmt:expr) => (print!(concat!($fmt, "\n"))); ($fmt:expr, $($arg:tt)*) => (print!(concat!($fmt, "\n"), $($arg)*)); @@ -394,7 +394,7 @@ It just adds a `\n` and then invokes the [`print!` macro], which is defined as: [`print!` macro]: https://doc.rust-lang.org/nightly/std/macro.print!.html -``` +```rust macro_rules! print { ($($arg:tt)*) => ($crate::io::_print(format_args!($($arg)*))); } @@ -405,12 +405,13 @@ It calls the `_print` method in the `io` module of the current crate (`$crate`), To print to the VGA buffer, we just copy the `println!` macro and modify the `print!` macro to use our static `WRITER` instead of `_print`: -``` +```rust // in src/vga_buffer.rs macro_rules! print { ($($arg:tt)*) => ({ use core::fmt::Write; - $crate::vga_buffer::WRITER.lock().write_fmt(format_args!($($arg)*)).unwrap(); + let writer = $crate::vga_buffer::WRITER.lock(); + writer.write_fmt(format_args!($($arg)*)).unwrap(); }); } ``` diff --git a/blog/post/2015-11-15-allocating-frames.md b/blog/post/2015-11-15-allocating-frames.md index c86555fd..294b6d7c 100644 --- a/blog/post/2015-11-15-allocating-frames.md +++ b/blog/post/2015-11-15-allocating-frames.md @@ -68,11 +68,13 @@ To print all available memory areas, we can use the `multiboot2` crate in our `r ```rust let boot_info = unsafe{ multiboot2::load(multiboot_information_address) }; -let memory_map_tag = boot_info.memory_map_tag().expect("Memory map tag required"); +let memory_map_tag = boot_info.memory_map_tag() + .expect("Memory map tag required"); println!("memory areas:"); for area in memory_map_tag.memory_areas() { - println!(" start: 0x{:x}, length: 0x{:x}", area.base_addr, area.length); + println!(" start: 0x{:x}, length: 0x{:x}", + area.base_addr, area.length); } ``` The `load` function is `unsafe` because it relies on a valid address. Since the memory tag is not required by the Multiboot specification, the `memory_map_tag()` function returns an `Option`. The `memory_areas()` function returns the desired memory area iterator. @@ -397,7 +399,7 @@ The [next post] will be about paging again. We will use the frame allocator to c [next post]: {{% relref "2015-12-09-modifying-page-tables.md" %}} ## Recommended Posts -Eric Kidd started the [Bare Metal Rust] series last week. Like this post, it builds upon the code from [Printing to Screen], but tries to support keyboard input instead of wrestling through memory management details ;). +Eric Kidd started the [Bare Metal Rust] series last week. Like this post, it builds upon the code from [Printing to Screen], but tries to support keyboard input instead of wrestling through memory management details. [Bare Metal Rust]: http://www.randomhacks.net/bare-metal-rust/ [Printing to Screen]: {{% relref "2015-10-23-printing-to-screen.md" %}} diff --git a/blog/post/2015-12-09-modifying-page-tables.md b/blog/post/2015-12-09-modifying-page-tables.md index 69bbf7ea..b6a0ee76 100644 --- a/blog/post/2015-12-09-modifying-page-tables.md +++ b/blog/post/2015-12-09-modifying-page-tables.md @@ -137,7 +137,9 @@ To extract the physical address, we add a `pointed_frame` method: ```rust pub fn pointed_frame(&self) -> Option { if self.flags().contains(PRESENT) { - Some(Frame::containing_address(self.0 as usize & 0x000fffff_fffff000)) + Some(Frame::containing_address( + self.0 as usize & 0x000fffff_fffff000 + )) } else { None } @@ -319,7 +321,9 @@ Note that `self` stays borrowed as long as the returned reference is valid. This ```rust pub fn next_table<'a>(&'a self, index: usize) -> Option<&'a Table> {...} -pub fn next_table_mut<'a>(&'a mut self, index: usize) -> Option<&'a mut Table> {...} +pub fn next_table_mut<'a>(&'a mut self, index: usize) + -> Option<&'a mut Table> +{...} ``` Note the additional lifetime parameters, which are identical for input and output references. That's exactly what we want. It ensures that we can't modify tables as long as we have references to lower tables. For example, it would be very bad if we could unmap a P3 table if we still write to one of its P2 tables. @@ -397,7 +401,8 @@ impl Table where L: HierarchicalLevel { pub fn next_table(&self, index: usize) -> Option<&Table> {...} - pub fn next_table_mut(&mut self, index: usize) -> Option<&mut Table> {...} + pub fn next_table_mut(&mut self, index: usize) -> Option<&mut Table> + {...} fn next_table_address(&self, index: usize) -> Option {...} } @@ -454,7 +459,9 @@ Remember that this is bare metal kernel code. We just used type system magic to Now let's do something useful with our new module. We will create a function that translates a virtual address to the corresponding physical address. We add it to the `paging/mod.rs` module: ```rust -pub fn translate(virtual_address: VirtualAddress) -> Option { +pub fn translate(virtual_address: VirtualAddress) + -> Option +{ let offset = virtual_address % PAGE_SIZE; translate_page(Page::containing_address(virtual_address)) .map(|frame| frame.number * PAGE_SIZE + offset) @@ -464,7 +471,8 @@ It uses two functions we haven't defined yet: `translate_page` and `Page::contai ```rust pub fn containing_address(address: VirtualAddress) -> Page { - assert!(address < 0x0000_8000_0000_0000 || address >= 0xffff_8000_0000_0000, + assert!(address < 0x0000_8000_0000_0000 || + address >= 0xffff_8000_0000_0000, "invalid address: 0x{:x}", address); Page { number: address / PAGE_SIZE } } @@ -543,8 +551,8 @@ p3.and_then(|p3| { // address must be 1GiB aligned assert!(start_frame.number % (ENTRY_COUNT * ENTRY_COUNT) == 0); return Some(Frame { - number: start_frame.number + page.p2_index() * ENTRY_COUNT + - page.p1_index(), + number: start_frame.number + page.p2_index() * + ENTRY_COUNT + page.p1_index(), }); } } @@ -573,7 +581,8 @@ Let's add a function that modifies the page tables to map a `Page` to a `Frame`: pub use self::entry::*; use memory::FrameAllocator; -pub fn map_to(page: Page, frame: Frame, flags: EntryFlags, allocator: &mut A) +pub fn map_to(page: Page, frame: Frame, flags: EntryFlags, + allocator: &mut A) where A: FrameAllocator { let p4 = unsafe { &mut *P4 }; diff --git a/blog/post/2016-01-01-remap-the-kernel.md b/blog/post/2016-01-01-remap-the-kernel.md index 4d7e4675..fd1d9cf8 100644 --- a/blog/post/2016-01-01-remap-the-kernel.md +++ b/blog/post/2016-01-01-remap-the-kernel.md @@ -6,6 +6,8 @@ updated = "2016-03-06" In this post we will create a new page table to map the kernel sections correctly. Therefor we will extend the paging module to support modifications of _inactive_ page tables as well. Then we will switch to the new table and secure our kernel stack by creating a guard page. + + As always, you can find the source code on [Github]. Don't hesitate to file issues there if you have any problems or improvement suggestions. There is also a comment section at the end of this page. Note that this post requires a current Rust nightly. [Github]: https://github.com/phil-opp/blog_os/tree/remap_the_kernel @@ -27,16 +29,16 @@ _Updates_: ## Motivation In the [previous post], we had a strange bug in the `unmap` function. Its reason was a silent stack overflow, which corrupted the page tables. Fortunately, our kernel stack is right above the page tables so that we noticed the overflow relatively quickly. This won't be the case when we add threads with new stacks in the future. Then a silent stack overflow could overwrite some data without us noticing. But eventually some completely unrelated function fails because a variable changed its value. -[previous post]: {{ page.previous.url }} +[previous post]: {{% relref "2015-12-09-modifying-page-tables.md" %}} As you can imagine, these kinds of bugs are horrendous to debug. For that reason we will create a new hierarchical page table in this post, which has _guard page_ below the stack. A guard page is basically an unmapped page that causes a page fault when accessed. Thus we can catch stack overflows right when they happen. Also, we will use the [information about kernel sections] to map the various sections individually instead of blindly mapping the first gigabyte. To improve safety even further, we will set the correct page table flags for the various sections. Thus it won't be possible to modify the contents of `.text` or to execute code from `.data` anymore. -[information about kernel sections]: {% post_url 2015-11-15-allocating-frames %}#kernel-elf-sections +[information about kernel sections]: {{% relref "2015-11-15-allocating-frames.md#kernel-elf-sections" %}} ## Preparation There are many things that can go wrong when we switch to a new table. Therefore it's a good idea to [set up a debugger][set up gdb]. You should not need it when you follow this post, but it's good to know how to debug a problem when it occurs[^fn-debug-notes]. -[set up gdb]: /set-up-gdb.html +[set up gdb]: {{% relref "set-up-gdb.md" %}} [^fn-debug-notes]: For this post the most useful GDB command is probably `p/x *((long int*)0xfffffffffffff000)@512`. It prints all entries of the recursively mapped P4 table by interpreting it as an array of 512 long ints (the `@512` is GDB's array syntax). Of course you can also print other tables by adjusting the address. We also update the `Page` and `Frame` types to make our lives easier. The `Page` struct gets some derived traits: @@ -275,8 +277,8 @@ Now our `TemporaryPage` type is nearly complete. We only add one more method for ```rust use super::table::{Table, Level1}; -/// Maps the temporary page to the given page table frame in the active table. -/// Returns a reference to the now mapped table. +/// Maps the temporary page to the given page table frame in the active +/// table. Returns a reference to the now mapped table. pub fn map_table_frame(&mut self, frame: Frame, active_table: &mut ActivePageTable) @@ -285,7 +287,7 @@ pub fn map_table_frame(&mut self, } ``` This function interprets the given frame as a page table frame and returns a `Table` reference. We return a table of level 1 because it [forbids calling the `next_table` methods][some clever solution]. Calling `next_table` must not be possible since it's not a page of the recursive mapping. To be able to return a `Table`, we need to make the `Level1` enum in `memory/paging/table.rs` public. -[some clever solution]: {% post_url 2015-12-09-modifying-page-tables %}#some-clever-solution +[some clever solution]: {{% relref "2015-12-09-modifying-page-tables.md#some-clever-solution" %}} The `unsafe` block is safe since the `VirtualAddress` returned by the `map` function is always valid and the type cast just reinterprets the frame's content. @@ -317,7 +319,8 @@ impl InactivePageTable { temporary_page: &mut TemporaryPage) -> InactivePageTable { { - let table = temporary_page.map_table_frame(frame.clone(), active_table); + let table = temporary_page.map_table_frame(frame.clone(), + active_table); // now we are able to zero the table table.zero(); // set up recursive mapping for the table @@ -461,7 +464,9 @@ To backup the physical P4 frame of the active table, we can either read it from ```rust use x86::controlregs; -let backup = Frame::containing_address(unsafe { controlregs::cr3() } as usize); +let backup = Frame::containing_address( + unsafe { controlregs::cr3() } as usize +); ``` Why is it unsafe? Because reading the CR3 register leads to a CPU exception if the processor is not running in kernel mode ([Ring 0]). But this code will always run in kernel mode, so the `unsafe` block is completely safe here. @@ -552,7 +557,7 @@ pub fn remap_the_kernel(allocator: &mut A, boot_info: &BootInformation) First, we create a temporary page at page number `0xcafebabe`. We could use `0xdeadbeaf` or `0x123456789` as well, as long as the page is unused. The `active_table` and the `new_table` are created using their constructor functions. Then we use the `with` function to temporary change the recursive mapping and execute the closure as if the `new_table` were active. This allows us to map the sections in the new table without changing the active mapping. To get the kernel sections, we use the [Multiboot information structure]. -[Multiboot information structure]: {% post_url 2015-11-15-allocating-frames %}#the-multiboot-information-structure +[Multiboot information structure]: {{% relref "2015-11-15-allocating-frames.md#the-multiboot-information-structure" %}} Let's resolve the above `TODO` by identity mapping the sections: @@ -693,7 +698,9 @@ Time to test it! We reexport the `remap_the_kernel` function from the memory mod ```rust // in src/memory/mod.rs pub use self::paging::remap_the_kernel; +``` +```rust // in src/lib.rs #[no_mangle] pub extern "C" fn rust_main(multiboot_information_address: usize) { @@ -703,15 +710,18 @@ pub extern "C" fn rust_main(multiboot_information_address: usize) { vga_buffer::clear_screen(); println!("Hello World{}", "!"); - let boot_info = unsafe { multiboot2::load(multiboot_information_address) }; + let boot_info = unsafe { + multiboot2::load(multiboot_information_address) + }; let memory_map_tag = boot_info.memory_map_tag() .expect("Memory map tag required"); let elf_sections_tag = boot_info.elf_sections_tag() .expect("Elf sections tag required"); - let kernel_start = elf_sections_tag.sections().map(|s| s.addr).min().unwrap(); - let kernel_end = elf_sections_tag.sections().map(|s| s.addr + s.size).max() - .unwrap(); + let kernel_start = elf_sections_tag.sections().map(|s| s.addr) + .min().unwrap(); + let kernel_end = elf_sections_tag.sections().map(|s| s.addr + s.size) + .max().unwrap(); let multiboot_start = multiboot_information_address; let multiboot_end = multiboot_start + (boot_info.total_size as usize); @@ -748,7 +758,9 @@ pub fn switch(&mut self, new_table: InactivePageTable) -> InactivePageTable { use x86::controlregs; let old_table = InactivePageTable { - p4_frame: Frame::containing_address(unsafe { controlregs::cr3() } as usize), + p4_frame: Frame::containing_address( + unsafe { controlregs::cr3() } as usize + ), }; unsafe { controlregs::cr3_write(new_table.p4_frame.start_address() as u64); @@ -778,7 +790,7 @@ Let's cross our fingers and run it… ### Debugging A QEMU boot load indicates that some CPU exception occured. We can see all thrown CPU exception by starting QEMU with `-d int` (as described [here][qemu debugging]): -[qemu debugging]: {% post_url 2015-09-02-set-up-rust %}#debugging +[qemu debugging]: {{% relref "2015-09-02-set-up-rust.md#debugging" %}} ```bash > qemu-system-x86_64 -d int -no-reboot -cdrom build/os-x86_64.iso @@ -798,12 +810,12 @@ These lines are the important ones. We can read many useful information from the [page fault error code]: http://wiki.osdev.org/Exceptions#Error_code - `IP=0008:000000000010ab97` or `pc=000000000010ab97`: The program counter register tells us that the exception occurred when the CPU tried to execute the instruction at `0x10ab97`. We can disassemble this address to see the corresponding function. The `0008:` prefix in `IP` indicates the code [GDT segment]. -[GDT segment]: {% post_url 2015-08-25-entering-longmode %}#loading-the-gdt +[GDT segment]: {{% relref "2015-08-25-entering-longmode.md#loading-the-gdt" %}} - `SP=0010:00000000001182d0`: The stack pointer was `0x1182d0` (the `0010:` prefix indicates the data [GDT segment]). This tells us if it the stack overflowed. - `CR2=00000000000b8f00`: Finally the most useful register. It tells us which virtual address caused the page fault. In our case it's `0xb8f00`, which is part of the [VGA text buffer]. -[VGA text buffer]: {% post_url 2015-10-23-printing-to-screen %}#the-vga-text-buffer +[VGA text buffer]: {{% relref "2015-10-23-printing-to-screen.md#the-vga-text-buffer" %}} So let's find out which function caused the exception: @@ -998,7 +1010,7 @@ If we haven't forgotten to set the `WRITABLE` flag somewhere, it should still wo The final step is to create a guard page for our kernel stack. The decision to place the kernel stack right above the page tables was already useful to detect a silent stack overflow in the [previous post][silent stack overflow]. Now we profit from it again. Let's look at our assembly `.bss` section again to understand why: -[silent stack overflow]: {% post_url 2015-12-09-modifying-page-tables %}#translate +[silent stack overflow]: {{% relref "2015-12-09-modifying-page-tables.md#translate" %}} ```nasm ; in src/arch/x86_64/boot.asm @@ -1032,7 +1044,9 @@ pub fn remap_the_kernel(allocator: &mut A, boot_info: &BootInformation) // below is the new part // turn the old p4 page into a guard page - let old_p4_page = Page::containing_address(old_table.p4_frame.start_address()); + let old_p4_page = Page::containing_address( + old_table.p4_frame.start_address() + ); active_table.unmap(old_p4_page, allocator); println!("guard page at {:#x}", old_p4_page.start_address()); } @@ -1056,7 +1070,7 @@ Unfortunately stack probes require compiler support. They already work on Window ## What's next? Now that we have a (mostly) safe kernel stack and a working page table module, we can add a virtual memory allocator. The [next post] will explore Rust's allocator API and create a very basic allocator. At the end of that post, we will be able to use Rust's allocation and collections types such as [Box], [Vec], or even [BTreeMap]. -[next post]: {{ page.next.url }} +[next post]: {{% relref "2016-04-11-kernel-heap.md" %}} [Box]: https://doc.rust-lang.org/nightly/alloc/boxed/struct.Box.html [Vec]: https://doc.rust-lang.org/nightly/collections/vec/struct.Vec.html [BTreeMap]: https://doc.rust-lang.org/nightly/collections/struct.BTreeMap.html