Convert all external links to https (if supported)

blog/content/first-edition/posts/01-multiboot-kernel/index.md

@@ -9,7 +9,7 @@ template = "first-edition/page.html"
 
 This post explains how to create a minimal x86 operating system kernel using the Multiboot standard. In fact, it will just boot and print `OK` to the screen. In subsequent blog posts we will extend it using the [Rust] programming language.
 
-[Rust]: http://www.rust-lang.org/
+[Rust]: https://www.rust-lang.org/
 
 <!-- more -->
 
@@ -28,19 +28,19 @@ When you turn on a computer, it loads the [BIOS] from some special flash memory.
 
 [BIOS]: https://en.wikipedia.org/wiki/BIOS
 [protected mode]: https://en.wikipedia.org/wiki/Protected_mode
-[real mode]: http://wiki.osdev.org/Real_Mode
+[real mode]: https://wiki.osdev.org/Real_Mode
 
 We won't write a bootloader because that would be a complex project on its own (if you really want to do it, check out [_Rolling Your Own Bootloader_]). Instead we will use one of the [many well-tested bootloaders][bootloader comparison] out there to boot our kernel from a CD-ROM. But which one?
 
-[_Rolling Your Own Bootloader_]: http://wiki.osdev.org/Rolling_Your_Own_Bootloader
+[_Rolling Your Own Bootloader_]: https://wiki.osdev.org/Rolling_Your_Own_Bootloader
 [bootloader comparison]: https://en.wikipedia.org/wiki/Comparison_of_boot_loaders
 
 ## Multiboot
 Fortunately there is a bootloader standard: the [Multiboot Specification][multiboot]. Our kernel just needs to indicate that it supports Multiboot and every Multiboot-compliant bootloader can boot it. We will use the Multiboot 2 specification ([PDF][Multiboot 2]) together with the well-known [GRUB 2] bootloader.
 
 [multiboot]: https://en.wikipedia.org/wiki/Multiboot_Specification
-[multiboot 2]: http://nongnu.askapache.com/grub/phcoder/multiboot.pdf
-[grub 2]: http://wiki.osdev.org/GRUB_2
+[multiboot 2]: https://nongnu.askapache.com/grub/phcoder/multiboot.pdf
+[grub 2]: https://wiki.osdev.org/GRUB_2
 
 To indicate our Multiboot 2 support to the bootloader, our kernel must start with a _Multiboot Header_, which has the following format:
 
@@ -130,7 +130,7 @@ Through assembling, viewing and disassembling we can see the CPU [Opcodes] in ac
 To boot our executable later through GRUB, it should be an [ELF] executable. So we want `nasm` to create ELF [object files] instead of plain binaries. To do that, we simply pass the `‑f elf64` argument to it.
 
 [ELF]: https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
-[object files]: http://wiki.osdev.org/Object_Files
+[object files]: https://wiki.osdev.org/Object_Files
 
 To create the ELF _executable_, we need to [link] the object files together. We use a custom [linker script] named `linker.ld`:
 

blog/content/first-edition/posts/02-entering-longmode/index.md

@@ -12,7 +12,7 @@ updated = "2015-10-29"
 In the [previous post] we created a minimal multiboot kernel. It just prints `OK` and hangs. The goal is to extend it and call 64-bit [Rust] code. But the CPU is currently in [protected mode] and allows only 32-bit instructions and up to 4GiB memory. So we need to set up _Paging_ and switch to the 64-bit [long mode] first.
 
 [previous post]: @/first-edition/posts/01-multiboot-kernel/index.md
-[Rust]: http://www.rust-lang.org/
+[Rust]: https://www.rust-lang.org/
 [protected mode]: https://en.wikipedia.org/wiki/Protected_mode
 [long mode]: https://en.wikipedia.org/wiki/Long_mode
 
@@ -47,7 +47,7 @@ A screen character consists of a 8 bit color code and a 8 bit [ASCII] character.
 
 Now we can add some check _functions_. A function is just a normal label with an `ret` (return) instruction at the end. The `call` instruction can be used to call it. Unlike the `jmp` instruction that just jumps to a memory address, the `call` instruction will push a return address to the stack (and the `ret` will jump to this address). But we don't have a stack yet. The [stack pointer] in the esp register could point to some important data or even invalid memory. So we need to update it and point it to some valid stack memory.
 
-[stack pointer]: http://stackoverflow.com/a/1464052/866447
+[stack pointer]: https://stackoverflow.com/a/1464052/866447
 
 ### Creating a Stack
 To create stack memory we reserve some bytes at the end of our `boot.asm`:
@@ -96,14 +96,14 @@ We use the `cmp` instruction to compare the value in `eax` to the magic value. I
 
 In `no_multiboot`, we use the `jmp` (“jump”) instruction to jump to our error function. We could just as well use the `call` instruction, which additionally pushes the return address. But the return address is not needed because `error` never returns. To pass `0` as error code to the `error` function, we move it into `al` before the jump (`error` will read it from there).
 
-[Multiboot specification]: http://nongnu.askapache.com/grub/phcoder/multiboot.pdf
+[Multiboot specification]: https://nongnu.askapache.com/grub/phcoder/multiboot.pdf
 [FLAGS register]: https://en.wikipedia.org/wiki/FLAGS_register
 
 ### CPUID check
 [CPUID] is a CPU instruction that can be used to get various information about the CPU. But not every processor supports it. CPUID detection is quite laborious, so we just copy a detection function from the [OSDev wiki][CPUID detection]:
 
-[CPUID]: http://wiki.osdev.org/CPUID
-[CPUID detection]: http://wiki.osdev.org/Setting_Up_Long_Mode#Detection_of_CPUID
+[CPUID]: https://wiki.osdev.org/CPUID
+[CPUID detection]: https://wiki.osdev.org/Setting_Up_Long_Mode#Detection_of_CPUID
 
 ```nasm
 check_cpuid:
@@ -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]: http://wiki.osdev.org/Setting_Up_Long_Mode#x86_or_x86-64
+[long mode detection]: https://wiki.osdev.org/Setting_Up_Long_Mode#x86_or_x86-64
 
 ```nasm
 check_long_mode:
@@ -400,7 +400,7 @@ Bit(s)                | Name | Meaning
 54 | 32-bit | must be 0 for 64-bit segments
 55-63 | ignored | ignored in 64-bit mode
 
-[ring level]: http://wiki.osdev.org/Security#Rings
+[ring level]: https://wiki.osdev.org/Security#Rings
 
 We need one code segment, a data segment is not necessary in 64-bit mode. Code segments have the following bits set: _descriptor type_, _present_, _executable_ and the _64-bit_ flag. Translated to assembly the long mode GDT looks like this:
 
@@ -451,7 +451,7 @@ gdt64:
 ```
 We can't just use a normal label here, since we need the table _offset_. We calculate this offset using the current address `$` and set the label to this value using [equ]. Now we can use `gdt64.code` instead of 8 and this label will still work if we modify the GDT.
 
-[equ]: http://www.nasm.us/doc/nasmdoc3.html#section-3.2.4
+[equ]: https://www.nasm.us/doc/nasmdoc3.html#section-3.2.4
 
 In order to finally enter the true 64-bit mode, we need to load `cs` with `gdt64.code`. But we can't do it through `mov`. The only way to reload the code selector is a _far jump_ or a _far return_. These instructions work like a normal jump/return but change the code selector. We use a far jump to a long mode label:
 

blog/content/first-edition/posts/03-set-up-rust/index.md

@@ -36,7 +36,7 @@ The code from this post (and all following) is [automatically tested](https://tr
 ## Creating a Cargo project
 [Cargo] is Rust's excellent package manager. Normally you would call `cargo new` when you want to create a new project folder. We can't use it because our folder already exists, so we need to do it manually. Fortunately we only need to add a cargo configuration file named `Cargo.toml`:
 
-[Cargo]: http://doc.crates.io/guide.html
+[Cargo]: https://doc.crates.io/guide.html
 
 ```toml
 [package]
@@ -114,7 +114,7 @@ Rust allows us to define [custom targets] through a JSON configuration file. A m
 
 The `llvm-target` field specifies the target triple that is passed to LLVM. [Target triples] are a naming convention that define the CPU architecture (e.g., `x86_64` or `arm`), the vendor (e.g., `apple` or `unknown`), the operating system (e.g., `windows` or `linux`), and the [ABI] \(e.g., `gnu` or `msvc`). For example, the target triple for 64-bit Linux is `x86_64-unknown-linux-gnu` and for 32-bit Windows the target triple is `i686-pc-windows-msvc`.
 
-[Target triples]: http://llvm.org/docs/LangRef.html#target-triple
+[Target triples]: https://llvm.org/docs/LangRef.html#target-triple
 [ABI]: https://en.wikipedia.org/wiki/Application_binary_interface
 
 The `data-layout` field is also passed to LLVM and specifies how data should be laid out in memory. It consists of various specifications separated by a `-` character. For example, the `e` means little endian and `S128` specifies that the stack should be 128 bits (= 16 byte) aligned. The format is described in detail in the [LLVM documentation][data layout] but there shouldn't be a reason to change this string.
@@ -126,7 +126,7 @@ The `linker-flavor` field was recently introduced in [#40018] with the intention
 
 The other fields are used for conditional compilation. This allows crate authors to use `cfg` variables to write special code for depending on the OS or the architecture. There isn't any up-to-date documentation about these fields but the [corresponding source code][target specification] is quite readable.
 
-[data layout]: http://llvm.org/docs/LangRef.html#data-layout
+[data layout]: https://llvm.org/docs/LangRef.html#data-layout
 [target specification]: https://github.com/rust-lang/rust/blob/c772948b687488a087356cb91432425662e034b9/src/librustc_back/target/mod.rs#L194-L214
 
 ### A Kernel Target Specification
@@ -152,8 +152,8 @@ As `llvm-target` we use `x86_64-unknown-none`, which defines the `x86_64` archit
 #### The Red Zone
 The [red zone] is an optimization of the [System V ABI] that allows functions to temporary use the 128 bytes below its stack frame without adjusting the stack pointer:
 
-[red zone]: http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64#the-red-zone
-[System V ABI]: http://wiki.osdev.org/System_V_ABI
+[red zone]: https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64#the-red-zone
+[System V ABI]: https://wiki.osdev.org/System_V_ABI
 
 ![stack frame with red zone](red-zone.svg)
 
@@ -167,7 +167,7 @@ However, this optimization leads to huge problems with exceptions or hardware in
 
 The CPU and the exception handler overwrite the data in red zone. But this data is still needed by the interrupted function. So the function won't work correctly anymore when we return from the exception handler. This might lead to strange bugs that [take weeks to debug].
 
-[take weeks to debug]: http://forum.osdev.org/viewtopic.php?t=21720
+[take weeks to debug]: https://forum.osdev.org/viewtopic.php?t=21720
 
 To avoid such bugs when we implement exception handling in the future, we disable the red zone right from the beginning. This is achieved by adding the `"disable-redzone": true` line to our target configuration file.
 

blog/content/first-edition/posts/04-printing-to-screen/index.md

@@ -205,7 +205,7 @@ error[E0507]: cannot move out of borrowed content
 The reason it that Rust _moves_ values by default instead of copying them like other languages. And we cannot move `color_code` out of `self` because we only borrowed `self`. For more information check out the [ownership section] in the Rust book.
 
 [ownership section]: https://doc.rust-lang.org/book/ownership.html
-[by reference]: http://rust-lang.github.io/book/ch04-02-references-and-borrowing.html
+[by reference]: https://rust-lang.github.io/book/ch04-02-references-and-borrowing.html
 
 To fix it, we can implement the [Copy] trait for the `ColorCode` type. The easiest way to do this is to use the built-in [derive macro]:
 
@@ -287,8 +287,8 @@ volatile = "0.1.0"
 
 The `0.1.0` is the [semantic] version number. For more information, see the [Specifying Dependencies] guide of the cargo documentation.
 
-[semantic]: http://semver.org/
-[Specifying Dependencies]: http://doc.crates.io/specifying-dependencies.html
+[semantic]: https://semver.org/
+[Specifying Dependencies]: https://doc.crates.io/specifying-dependencies.html
 
 Now we've declared that our project depends on the `volatile` crate and are able to import it in `src/lib.rs`:
 
@@ -354,7 +354,7 @@ You can try it yourself in the `print_something` function.
 When you print strings with some special characters like `ä` or `λ`, you'll notice that they cause weird symbols on screen. That's because they are represented by multiple bytes in [UTF-8]. By converting them to bytes, we of course get strange results. But since the VGA buffer doesn't support UTF-8, it's not possible to display these characters anyway.
 
 [core tracking issue]: https://github.com/rust-lang/rust/issues/27701
-[UTF-8]: http://www.fileformat.info/info/unicode/utf8.htm
+[UTF-8]: https://www.fileformat.info/info/unicode/utf8.htm
 
 ### Support Formatting Macros
 It would be nice to support Rust's formatting macros, too. That way, we can easily print different types like integers or floats. To support them, we need to implement the [core::fmt::Write] trait. The only required method of this trait is `write_str` that looks quite similar to our `write_str` method. To implement the trait, we just need to move it into an `impl fmt::Write for Writer` block and add a return type:
@@ -657,7 +657,7 @@ _Note_: You need to [cross compile binutils] to build it (or you create some sym
 - [Redox]: Probably the most complete Rust OS today. It has an active community and over 1000 Github stars. File systems, network, an audio player, a picture viewer, and much more. Just take a look at the [screenshots][redox screenshots].
 
 [Rust Bare-Bones Kernel]: https://github.com/thepowersgang/rust-barebones-kernel
-[higher half]: http://wiki.osdev.org/Higher_Half_Kernel
+[higher half]: https://wiki.osdev.org/Higher_Half_Kernel
 [cross compile binutils]: @/first-edition/extra/cross-compile-binutils.md
 [RustOS]: https://github.com/RustOS-Fork-Holding-Ground/RustOS
 ["Tifflin" Experimental Kernel]:https://github.com/thepowersgang/rust_os

blog/content/first-edition/posts/05-allocating-frames/index.md

@@ -71,7 +71,7 @@ Now we can use it to print available memory areas.
 ### Available Memory
 The boot information structure consists of various _tags_. See section 3.4 of the Multiboot specification ([PDF][multiboot specification]) for a complete list. The _memory map_ tag contains a list of all available RAM areas. Special areas such as the VGA text buffer at `0xb8000` are not available. Note that some of the available memory is already used by our kernel and by the multiboot information structure itself.
 
-[multiboot specification]: http://nongnu.askapache.com/grub/phcoder/multiboot.pdf
+[multiboot specification]: https://nongnu.askapache.com/grub/phcoder/multiboot.pdf
 
 To print all available memory areas, we can use the `multiboot2` crate in our `rust_main` as follows:
 
@@ -100,7 +100,7 @@ So we have one area from `0x0` to `0x9fc00`, which is a bit below the 1MiB mark.
 
 If you give QEMU more than 4GiB of memory by passing `-m 5G`, you get another unusable area below the 4GiB mark. This memory is normally mapped to some hardware devices. See the [OSDev Wiki][Memory_map] for more information.
 
-[Memory_map]: http://wiki.osdev.org/Memory_Map_(x86)
+[Memory_map]: https://wiki.osdev.org/Memory_Map_(x86)
 
 ### Handling Panics
 We used `expect` in the code above, which will panic if there is no memory map tag. But our current panic handler just loops without printing any error message. Of course we could replace `expect` by a `match`, but we should fix the panic handler nonetheless:
@@ -217,7 +217,7 @@ We could create some kind of linked list from the free frames. For example, each
 
 Another approach is to create some kind of data structure such as a [bitmap or a stack] to manage free frames. We could place it in the already identity mapped area right behind the kernel or multiboot structure. That way we would not need to (temporary) map each free frame. But it has the same problem of the slow initial creating/filling. In fact, we will use this approach in a future post to manage frames that are freed again. But for the initial management of free frames, we use a different method.
 
-[bitmap or a stack]: http://wiki.osdev.org/Page_Frame_Allocation#Physical_Memory_Allocators
+[bitmap or a stack]: https://wiki.osdev.org/Page_Frame_Allocation#Physical_Memory_Allocators
 
 In the following, we will use Multiboot's memory map directly. The idea is to maintain a simple counter that starts at frame 0 and is increased constantly. If the current frame is available (part of an available area in the memory map) and not used by the kernel or the multiboot structure (we know their start and end addresses), we know that it's free and return it. Else, we increase the counter to the next possibly free frame. That way, we don't need to create a data structure when booting and the physical frames can remain unmapped. The only problem is that we cannot reasonably free frames again, but we will solve that problem in a future post (by adding an intermediate frame stack that saves freed frames).
 
@@ -421,7 +421,7 @@ for i in 0.. {
 ```
 You can try different amounts of memory by passing e.g. `-m 500M` to QEMU. To compare these numbers, [WolframAlpha] can be very helpful.
 
-[WolframAlpha]: http://www.wolframalpha.com/input/?i=%2832605+*+4096%29+bytes+in+MiB
+[WolframAlpha]: https://www.wolframalpha.com/input/?i=%2832605+*+4096%29+bytes+in+MiB
 
 ## Conclusion
 

blog/content/first-edition/posts/07-remap-the-kernel/index.md

@@ -368,7 +368,7 @@ pub fn with<F>(&mut self,
 ```
 It overwrites the 511th P4 entry and points it to the inactive table frame. Then it flushes the [translation lookaside buffer (TLB)][TLB], which still contains some old translations. We need to flush all pages that are part of the recursive mapping, so the easiest way is to flush the TLB completely.
 
-[TLB]: http://wiki.osdev.org/TLB
+[TLB]: https://wiki.osdev.org/TLB
 
 
 Now that the recursive mapping points to the given inactive table, we execute the closure in the new context. The closure can call all active table methods such as `translate` or `map_to`. It could even call `with` again and chain another inactive table! Wait… that would not work:
@@ -466,7 +466,7 @@ let backup = Frame::containing_address(
 ```
 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.
 
-[Ring 0]: http://wiki.osdev.org/Security#Low-level_Protection_Mechanisms
+[Ring 0]: https://wiki.osdev.org/Security#Low-level_Protection_Mechanisms
 
 Now that we have a backup of the original P4 frame, we need a way to restore it after the closure has run. So we need to somehow modify the 511th entry of the original P4 frame, which is still the active table in the CPU. But we can't access it because the recursive mapping now points to the inactive table:
 
@@ -826,9 +826,9 @@ These lines are the important ones. We can read many useful information from the
 
 - `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].
 
-[osdev exception overview]: http://wiki.osdev.org/Exceptions
-[page fault]: http://wiki.osdev.org/Exceptions#Page_Fault
-[page fault error code]: http://wiki.osdev.org/Exceptions#Error_code
+[osdev exception overview]: https://wiki.osdev.org/Exceptions
+[page fault]: https://wiki.osdev.org/Exceptions#Page_Fault
+[page fault error code]: https://wiki.osdev.org/Exceptions#Error_code
 [GDT segment]: @/first-edition/posts/02-entering-longmode/index.md#loading-the-gdt
 [VGA text buffer]: @/first-edition/posts/04-printing-to-screen/index.md#the-vga-text-buffer
 

blog/content/first-edition/posts/08-kernel-heap/index.md

@@ -34,7 +34,7 @@ A good allocator is fast and reliable. It also effectively utilizes the availabl
 
 [cache locality]: http://docs.cray.com/books/S-2315-50/html-S-2315-50/qmeblljm.html
 [fragmentation]: https://en.wikipedia.org/wiki/Fragmentation_(computing)
-[false sharing]: http://mechanical-sympathy.blogspot.de/2011/07/false-sharing.html
+[false sharing]: https://mechanical-sympathy.blogspot.de/2011/07/false-sharing.html
 
 These requirements make good allocators pretty complex. For example, [jemalloc] has over 30.000 lines of code. This complexity is out of scope for our kernel, so we will create a much simpler allocator. Nevertheless, it should suffice for the foreseeable future, since we'll allocate only when it's absolutely necessary.
 
@@ -344,7 +344,7 @@ check_exception old: 0xffffffff new 0xe
 ```
 Aha! It's a [page fault] \(`v=0e`) and was caused by the code at `0x102860`. The code tried to write (`e=0002`) to address `0x40000000`. This address is `0o_000_001_000_000_0000` in octal, which is the `HEAP_START` address defined above. Of course it page-faults: We have forgotten to map the heap memory to some physical memory.
 
-[page fault]: http://wiki.osdev.org/Exceptions#Page_Fault
+[page fault]: https://wiki.osdev.org/Exceptions#Page_Fault
 
 ### Some Refactoring
 In order to map the heap cleanly, we do a bit of refactoring first. We move all memory initialization from our `rust_main` to a new `memory::init` function. Now our `rust_main` looks like this:

blog/content/first-edition/posts/09-handling-exceptions/index.md

@@ -9,7 +9,7 @@ template = "first-edition/page.html"
 
 In this post, we start exploring CPU exceptions. Exceptions occur in various erroneous situations, for example when accessing an invalid memory address or when dividing by zero. To catch them, we have to set up an _interrupt descriptor table_ that provides handler functions. At the end of this post, our kernel will be able to catch [breakpoint exceptions] and to resume normal execution afterwards.
 
-[breakpoint exceptions]: http://wiki.osdev.org/Exceptions#Breakpoint
+[breakpoint exceptions]: https://wiki.osdev.org/Exceptions#Breakpoint
 
 <!-- more -->
 
@@ -30,7 +30,7 @@ We've already seen several types of exceptions in our kernel:
 
 For the full list of exceptions check out the [OSDev wiki][exceptions].
 
-[exceptions]: http://wiki.osdev.org/Exceptions
+[exceptions]: https://wiki.osdev.org/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:
@@ -128,7 +128,7 @@ However, there is a major difference between exceptions and function calls: A fu
 [Calling conventions] specify the details of a function call. For example, they specify where function parameters are placed (e.g. in registers or on the stack) and how results are returned. On x86_64 Linux, the following rules apply for C functions (specified in the [System V ABI]):
 
 [Calling conventions]: https://en.wikipedia.org/wiki/Calling_convention
-[System V ABI]: http://refspecs.linuxbase.org/elf/gabi41.pdf
+[System V ABI]: https://refspecs.linuxbase.org/elf/gabi41.pdf
 
 - the first six integer arguments are passed in registers `rdi`, `rsi`, `rdx`, `rcx`, `r8`, `r9`
 - additional arguments are passed on the stack
@@ -221,11 +221,11 @@ pub fn init() {
 
 Now we can add handler functions. We start by adding a handler for the [breakpoint exception]. The breakpoint exception is the perfect exception to test exception handling. Its only purpose is to temporary pause a program when the breakpoint instruction `int3` is executed.
 
-[breakpoint exception]: http://wiki.osdev.org/Exceptions#Breakpoint
+[breakpoint exception]: https://wiki.osdev.org/Exceptions#Breakpoint
 
 The breakpoint exception is commonly used in debuggers: When the user sets a breakpoint, the debugger overwrites the corresponding instruction with the `int3` instruction so that the CPU throws the breakpoint exception when it reaches that line. When the user wants to continue the program, the debugger replaces the `int3` instruction with the original instruction again and continues the program. For more details, see the ["_How debuggers work_"] series.
 
-["_How debuggers work_"]: http://eli.thegreenplace.net/2011/01/27/how-debuggers-work-part-2-breakpoints
+["_How debuggers work_"]: https://eli.thegreenplace.net/2011/01/27/how-debuggers-work-part-2-breakpoints
 
 For our use case, we don't need to overwrite any instructions (it wouldn't even be possible since we [set the page table flags] to read-only). Instead, we just want to print a message when the breakpoint instruction is executed and then continue the program.
 
@@ -439,16 +439,16 @@ The answer is that the stored instruction pointer only points to the causing ins
 - **Aborts** are fatal exceptions that can't be recovered. Examples are [machine check exception] or the [double fault].
 - **Traps** are only reported to the kernel, but don't hinder the continuation of the program. Examples are the breakpoint exception and the [overflow exception].
 
-[page fault]: http://wiki.osdev.org/Exceptions#Page_Fault
-[machine check exception]: http://wiki.osdev.org/Exceptions#Machine_Check
-[double fault]: http://wiki.osdev.org/Exceptions#Double_Fault
-[overflow exception]: http://wiki.osdev.org/Exceptions#Overflow
+[page fault]: https://wiki.osdev.org/Exceptions#Page_Fault
+[machine check exception]: https://wiki.osdev.org/Exceptions#Machine_Check
+[double fault]: https://wiki.osdev.org/Exceptions#Double_Fault
+[overflow exception]: https://wiki.osdev.org/Exceptions#Overflow
 
 The reason for the diffent instruction pointer values is that the stored value is also the return address. So for faults, the instruction that caused the exception is restarted and might cause the same exception again if it's not resolved. This would not make much sense for traps, since invoking the breakpoint exception again would just cause another breakpoint exception[^fn-breakpoint-restart-use-cases]. Thus the instruction pointer points to the _next_ instruction for these exceptions.
 
 In some cases, the distinction between faults and traps is vague. For example, the [debug exception] behaves like a fault in some cases, but like a trap in others. So to find out the meaning of the saved instruction pointer, it is a good idea to read the official documentation for the exception, which can be found in the [AMD64 manual] in Section 8.2. For example, for the breakpoint exception it says:
 
-[debug exception]: http://wiki.osdev.org/Exceptions#Debug
+[debug exception]: https://wiki.osdev.org/Exceptions#Debug
 [AMD64 manual]: https://www.amd.com/system/files/TechDocs/24593.pdf
 
 > `#BP` is a trap-type exception. The saved instruction pointer points to the byte after the `INT3` instruction.
@@ -456,7 +456,7 @@ In some cases, the distinction between faults and traps is vague. For example, t
 The documentation of the [`Idt`] struct and the [OSDev Wiki][osdev wiki exceptions] also contain this information.
 
 [`Idt`]: https://docs.rs/x86_64/0.1.1/x86_64/structures/idt/struct.Idt.html
-[osdev wiki exceptions]: http://wiki.osdev.org/Exceptions
+[osdev wiki exceptions]: https://wiki.osdev.org/Exceptions
 
 ## Too much Magic?
 The `x86-interrupt` calling convention and the [`Idt`] type made the exception handling process relatively straightforward and painless. If this was too much magic for you and you like to learn all the gory details of exception handling, we got you covered: Our [“Handling Exceptions with Naked Functions”] series shows how to handle exceptions without the `x86-interrupt` calling convention and also creates its own `Idt` type. Historically, these posts were the main exception handling posts before the `x86-interrupt` calling convention and the `x86_64` crate existed.
@@ -466,8 +466,8 @@ The `x86-interrupt` calling convention and the [`Idt`] type made the exception h
 ## What's next?
 We've successfully caught our first exception and returned from it! The next step is to add handlers for other common exceptions such as page faults. We also need to make sure that we never cause a [triple fault], since it causes a complete system reset. The next post explains how we can avoid this by correctly catching [double faults].
 
-[triple fault]: http://wiki.osdev.org/Triple_Fault
-[double faults]: http://wiki.osdev.org/Double_Fault#Double_Fault
+[triple fault]: https://wiki.osdev.org/Triple_Fault
+[double faults]: https://wiki.osdev.org/Double_Fault#Double_Fault
 
 ## Footnotes
 [^fn-breakpoint-restart-use-cases]: There are valid use cases for restarting an instruction that caused a breakpoint. The most common use case is a debugger: When setting a breakpoint on some code line, the debugger overwrites the corresponding instruction with an `int3` instruction, so that the CPU traps when that line is executed. When the user continues execution, the debugger swaps in the original instruction and continues the program from the replaced instruction.

blog/content/first-edition/posts/10-double-faults/index.md

@@ -128,12 +128,12 @@ First Exception | Second Exception
 [Divide-by-zero],<br>[Invalid TSS],<br>[Segment Not Present],<br>[Stack-Segment Fault],<br>[General Protection Fault] | [Invalid TSS],<br>[Segment Not Present],<br>[Stack-Segment Fault],<br>[General Protection Fault]
 [Page Fault] | [Page Fault],<br>[Invalid TSS],<br>[Segment Not Present],<br>[Stack-Segment Fault],<br>[General Protection Fault]
 
-[Divide-by-zero]: http://wiki.osdev.org/Exceptions#Divide-by-zero_Error
-[Invalid TSS]: http://wiki.osdev.org/Exceptions#Invalid_TSS
-[Segment Not Present]: http://wiki.osdev.org/Exceptions#Segment_Not_Present
-[Stack-Segment Fault]: http://wiki.osdev.org/Exceptions#Stack-Segment_Fault
-[General Protection Fault]: http://wiki.osdev.org/Exceptions#General_Protection_Fault
-[Page Fault]: http://wiki.osdev.org/Exceptions#Page_Fault
+[Divide-by-zero]: https://wiki.osdev.org/Exceptions#Divide-by-zero_Error
+[Invalid TSS]: https://wiki.osdev.org/Exceptions#Invalid_TSS
+[Segment Not Present]: https://wiki.osdev.org/Exceptions#Segment_Not_Present
+[Stack-Segment Fault]: https://wiki.osdev.org/Exceptions#Stack-Segment_Fault
+[General Protection Fault]: https://wiki.osdev.org/Exceptions#General_Protection_Fault
+[Page Fault]: https://wiki.osdev.org/Exceptions#Page_Fault
 
 
 [AMD64 manual]: https://www.amd.com/system/files/TechDocs/24593.pdf
@@ -438,7 +438,7 @@ We allocate a 4096 bytes stack (one page) for our double fault handler. Now we j
 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 mode 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
-[hardware context switching]: http://wiki.osdev.org/Context_Switching#Hardware_Context_Switching
+[hardware context switching]: https://wiki.osdev.org/Context_Switching#Hardware_Context_Switching
 
 On x86_64, the TSS no longer holds any task specific information at all. Instead, it holds two stack tables (the IST is one of them). The only common field between the 32-bit and 64-bit TSS is the pointer to the [I/O port permissions bitmap].
 
@@ -608,7 +608,7 @@ Bit(s)                | Name | Meaning
 64-95 | **base 32-63** | the last four bytes of the base address
 96-127 | ignored/must be zero | bits 104-108 must be zero, the rest is ignored
 
-[ring level]: http://wiki.osdev.org/Security#Rings
+[ring level]: https://wiki.osdev.org/Security#Rings
 
 We only need the bold fields for our TSS descriptor. For example, we don't need the `limit 16-19` field since a TSS has a fixed size that is smaller than `2^16`.