Variable</th>	Memory Address</th>	Value</th></tr></thead>
...</td>	...</td>	...</td></tr>
s</strong></td>	0x16b446fc8</strong></td>	0x14fe060e0</strong></td></tr>
s2</strong></td>	0x16b446fc0</strong></td>	0x14fe060e0</strong></td></tr>
...</td>	...</td>	...</td></tr>
...</td>	...</td>	...</td></tr>
</td>	0x14fe060e0</strong></td>	1</strong></td></tr>
...</td>	...</td>	...</td></tr> </tbody></table> in Rust we trust Ownership and Borrowing</a>.</p> Boxing `Smart Pointers</a>.</p>` Moving</a> </h3> Now let's rearrange the code similar to the C one:</p> 1</span>//</span> #6</span></span> 2</span>//</span> main.rs</span></span> 3</span></span> 4</span>fn</span> main</span>(</span>)</span> {</span></span> 5</span> let</span> s</span> =</span> Box</span>::</span>new</span>(</span>1_</span>i32</span>)</span>;</span></span> 6</span> let</span> s2</span> =</span> s</span>;</span></span> 7</span></span> 8</span> //</span> Addresses of `s` and `s2` on the Stack</span></span> 9</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> &</span>s</span>)</span>;</span></span> 10</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> &</span>s2</span>)</span>;</span></span> 11</span></span> 12</span> //</span> Values directly stored in `s` and `s2`</span></span> 13</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> s</span>)</span>;</span></span> 14</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> s2</span>)</span>;</span></span> 15</span></span> 16</span> //</span> Actual values stored on the heap</span></span> 17</span> println!</span>(</span>"</span>{</span>}</span>"</span>,</span> s</span>)</span>;</span></span> 18</span> println!</span>(</span>"</span>{</span>}</span>"</span>,</span> s2</span>)</span>;</span></span> 19</span>}</span></span></code></pre> See that? I didn't add the result of the println!()</code> macros in front of them because this code doesn't compile!</p> Here is the compiler's error:</p> \|</span></span> 5 \| let s = Box::new(1_i32);</span></span> \| - move occurs because `s` has type `Box<i32>`, which does not implement the Copy trait</span></span> 6 \| let s2 = s;</span></span> \| - value moved here</span></span> …</span></span> 9 \| println!("{:p}", &s);</span></span> \| ^^ value borrowed here after move</span></span> \|</span></span> help: consider cloning the value if the performance cost is acceptable</span></span> \|</span></span> 6 \| let s2 = s.clone();</span></span> \| ++++++++</span></span></code></pre> Interesting!</p> Why did it worked in the code snippet number #5</code>? Keep reading!</p> Copy and Clone</a> </h3> Do you remember the first two ownership rules?</p> When the Box::new()</code> allocates a location on the heap and returns a pointer to it, the variable s</code> becomes the owner of that piece of memory. Deallocation happens when the owner goes out of scope</em>; in this case, the scope ends at the end of the main</code> function. This ensures that the memory gets freed automatically, without the need to manually call a free()</code>-like function, when it's no longer required.</p> By assigning s</code> to s2</code>, we are moving the ownership of the memory location pointed to by s</code>, to s2</code>, and since there can only be one owner at a time</em>, after the assignment operation, s</code> is no longer valid.</p> If we were to assign just the number 1</code> to s</code> (let s = 1_i32</code>), then the value would be stored on the stack, and when assigning s</code> to s2</code>, s2</code> would receive a fresh "Copy" of the value 1</code>, which is again stored on the stack and is completely unrelated to the value stored in s</code>. In Rust, Primitive types like integers and booleans are "Copy" which means they implement the Copy</code> trait, which means they can be copied around easily and, most importantly, cheaply.</p> Moving the ownership only happens to the variables that are storing a non-copy value. Although pointers are still numbers, in contrast to C, Rust treats them differently. In fact, Rust calls them References instead of Pointers.</p> Rust also has Pointers (a.k.a. "Raw Pointers"), which pretty much behave like what you would expect from a pointer in C, where there is no notion of Ownership and Borrowing. Raw Pointers cannot be used in "Safe Rust" and are used in scenarios like Foreign Function Interface (FFI)</a>.</p> It is also possible to make a "fresh copy" of a value stored on the heap. But in doing so, first, we need to allocate the required memory and then copy the value over. Memory allocations are considered to be costly operations; in general, we usually use heap memory to store values whose size is not known at compile time or values whose lifetime should cross function-call boundaries.</p> If a type is Copy</code>, by assigning it to another variable, the new variable would receive a bitwise copy of the old value and would become the owner of the new copy as well; and if the value doesn't implement the Copy</code> trait, the ownership of the old value would be moved over to the new variable and the old variable can no longer be used. Unless the programmer explicitly calls clone()</code>, which usually would cause an allocation to happen for the new value on the heap. On the other hand, if a value is Copy</code>, then calling clone()</code> would do nothing more than the implicit copy.</p> As a result, in Rust, Copying</em> is an implicit operation, while Cloning</em> is always explicit. Additionally, the implementation of Clone</code> can vary for different types based on their specific needs.</p> More information about Copy</code> and Clone</code> can be found here</a>.</p> Compiler-Driven Development (CDD)</a> </h3> Now we can also understand the help message: consider cloning the value if the performance cost is acceptable.</code></p> In Rust, the compiler is your best friend! So, with more theory behind us, we are hopefully more comfortable making sense of the compiler's messages. Being able to understand why the compiler is yelling at us is a crucial skill to develop while learning Rust.</p> Before continuing with more code, one last point is to understand why the first program, where the order of variable definition/assignments and println!()</code>s were different, worked.</p> That was because we didn't try to use the variable s</code> after its value moved to s2</code>, and the compiler was smart enough to realize that. Isn't that cool?!</p> The lifetime of s</code> ends after the move, and it should no longer be used, which was exactly what we did in the first Rust example. It's time to make our compiler friend happy again without rearranging the order of operations.</p> Borrowing</a> </h3> For that, we are going to borrow the value of s</code>. By doing so, s</code> would remain the owner:</p> 1</span>//</span> #7</span></span> 2</span>//</span> main.rs</span></span> 3</span></span> 4</span>fn</span> main</span>(</span>)</span> {</span></span> 5</span> let</span> s</span> =</span> Box</span>::</span>new</span>(</span>1_</span>i32</span>)</span>;</span></span> 6</span> let</span> s2</span> =</span> &</span>s</span>;</span></span> 7</span></span> 8</span> //</span> Addresses of `s` and `s2` on the Stack</span></span> 9</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> &</span>s</span>)</span>;</span> //</span> 0x16efee738</span></span> 10</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> &</span>s2</span>)</span>;</span> //</span> 0x16efee740</span></span> 11</span></span> 12</span> //</span> Values directly stored in `s` and `s2`</span></span> 13</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> s</span>)</span>;</span> //</span> 0x127e05f70</span></span> 14</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> s2</span>)</span>;</span> //</span> 0x16efee738</span></span> 15</span></span> 16</span> //</span> Actual values stored on the heap</span></span> 17</span> println!</span>(</span>"</span>{</span>}</span>"</span>,</span> s</span>)</span>;</span> //</span> 1</span></span> 18</span> println!</span>(</span>"</span>{</span>}</span>"</span>,</span> s2</span>)</span>;</span> //</span> 1</span></span> 19</span>}</span></span></code></pre> The value immediately stored in s2</code> is just the address of the variable s</code> on the stack. In Rust's terms, s2</code> is an immutable reference to s</code>.</p> What if we want to be able to mutate the inner value of the Box</code>?</p> All variables in Rust are immutable unless explicitly changed to be mutable using the mut</code> keyword. There are also types that provide interior mutability (Cell<T></code>, RefCell<T></code>, Mutex<T></code>, and RwLock<T></code>), but they are a topic for another time!</p> Order matters</a> </h3> Let's try that:</p> 1</span>//</span> #8</span></span> 2</span>//</span> main.rs</span></span> 3</span></span> 4</span>fn</span> main</span>(</span>)</span> {</span></span> 5</span> let</span> mut</span> s</span> =</span> Box</span>::</span>new</span>(</span>1_</span>i32</span>)</span>;</span></span> 6</span> </span>s</span> =</span> 2</span>;</span></span> 7</span> let</span> s2</span> =</span> &</span>s</span>;</span></span> 8</span></span> 9</span> //</span>...rest of the code...</span></span> 10</span> //</span> The only change in the results is that the final set of `println!()`</span></span> 11</span> //</span> macros will print 2 instead of 1, which is no surprise!</span></span> 12</span> //</span> Addresses might also change which is expected but their causal</span></span> 13</span> //</span> relationship stays the same.</span></span> 14</span>}</span></span></code></pre> The code snippet number #8</code> compiles fine but the next one (#9</code>) doesn't:</p> 1</span>//</span> #9</span></span> 2</span>//</span> main.rs</span></span> 3</span></span> 4</span>fn</span> main</span>(</span>)</span> {</span></span> 5</span> let</span> mut</span> s</span> =</span> Box</span>::</span>new</span>(</span>1_</span>i32</span>)</span>;</span></span> 6</span> let</span> s2</span> =</span> &</span>s</span>;</span></span> 7</span> </span>s</span> =</span> 2</span>;</span></span> 8</span></span> 9</span> //</span> Addresses of `s` and `s2` on the Stack</span></span> 10</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> &</span>s</span>)</span>;</span></span> 11</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> &</span>s2</span>)</span>;</span></span> 12</span>}</span></span></code></pre> Compilation fails with this error:</p> \|</span></span> 6 \| let s2 = &s;</span></span> \| -- `s` is borrowed here</span></span> 7 \| s = 2;</span></span> \| ^^^^^^ `s` is assigned to here but it was already borrowed</span></span> ...</span></span> 11 \| println!("{:p}", &s2);</span></span> \| --- borrow later used here</span></span></code></pre> Remembering the first rule of borrowing</em></p> At any given time, you can have either one mutable reference or any number of immutable references to a value.</p> </blockquote> In the code snippet number #8</code>, the value is borrowed after the mutation is done. So practically, the borrower will have a consistent view of the underlying memory. However, in snippet number #9</code>, the memory is mutated while there is a reference to it out there, which could potentially cause data races.</p> Ok, nice but we're getting a little bit carried away!</p> I will stop here to go back to the actual reason I thought this could be an interesting topic to discuss; To see if we could rewrite the exact C code in Rust without all that fancy borrowing stuff and by now, you are hopefully convinced it's not possible based on what we saw and experimented with.</p> Unsafe</a> </h3> So far, we have been writing code in Safe Rust</em> in which we have our compiler friend and its borrow checker as our supervisor. But there are certain situations such as interfacing with low-level system APIs (e.g., writing a device driver or calling foreign functions</a>) where we can't do much with the strict rules enforced by the borrow checker.</p> That's where we need to enter the Unsafe Rust</a></em>.</p> Here, the word unsafe</em> doesn't really mean unsafe. So whenever we write an unsafe {}</code> block, we are asking the compiler to trust us, and that we have made sure this code is safe to run.</p> Let's see how does that look like:</p> 1</span>//</span> #10</span></span> 2</span>//</span> main.rs</span></span> 3</span></span> 4</span>fn</span> main</span>(</span>)</span> {</span></span> 5</span> let</span> s</span> =</span> Box</span>::</span>new</span>(</span>1_</span>i32</span>)</span>;</span></span> 6</span> let</span> s2</span> =</span> unsafe</span> {</span> std</span>::</span>ptr</span>::</span>read</span>(</span>&</span>s</span>)</span> }</span>;</span></span> 7</span></span> 8</span> //</span> Addresses of `s` and `s2` on the Stack</span></span> 9</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> &</span>s</span>)</span>;</span></span> 10</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> &</span>s2</span>)</span>;</span></span> 11</span></span> 12</span> //</span> Values directly stored in `s` and `s2`</span></span> 13</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> s</span>)</span>;</span></span> 14</span> println!</span>(</span>"</span>{</span>:p</span>}</span>"</span>,</span> s2</span>)</span>;</span></span> 15</span></span> 16</span> //</span> Actual values stored on the heap</span></span> 17</span> println!</span>(</span>"</span>{</span>}</span>"</span>,</span> s</span>)</span>;</span></span> 18</span> println!</span>(</span>"</span>{</span>}</span>"</span>,</span> s2</span>)</span>;</span></span> 19</span>}</span></span></code></pre> If we simply write let s2 = unsafe { s };</code> it would still fail with the same error as let s2 = s;</code>. That's because s</code> still has type Box<i32></code>, which does not implement the Copy</code> trait!</p> What we want to do is to copy the memory address stored in s</code> into s2</code> without invalidating s</code> itself (i.e., without causing a move to happen). Specifically, want to create a bitwise copy of the value stores in s</code> and save it in s2</code> in order to mimic what C did (int s2 = s;</code>), right?</p> Luckily, the Rust standard library provides a function that exactly does that. std::ptr::read()</code> which has this signature:</p> pub</span> const</span> unsafe</span> fn</span> read</span>(</span>src</span>:</span> </span>const</span> T</span>)</span> → </span>T</span></span></code></pre> It reads the value from src</code> without moving it. This leaves the memory in src</code> unchanged.</p> Running the program prints this output to the console:</p> Finished dev [unoptimized + debuginfo] target(s) in 0.00s</span></span> Running `target/debug/blog`</span></span> 0x16d7566e8</span></span> 0x16d7566f0</span></span> 0x147605f70</span></span> 0x147605f70</span></span> 1</span></span> 1</span></span> blog(51595,0x1d6f31000) malloc: Double free of object 0x147605f70</span></span> blog(51595,0x1d6f31000) malloc: ** set a breakpoint in malloc_error_break to debug</span></span> [1] 51595 abort cargo run</span></span></code></pre> It executes and prints all addresses and values correctly but at the end, the program panics with this error message:</p> malloc: Double free of object 0x147605f70</span></span></code></pre>Aha Moment</a> </h3> Sounds familiar?</p> That's the mighty double-free issue we have been talking about which could easily happen in C but Rust is trying to solve, with its model of memory management.</p> Why did a double-free happen?</p> Remembering the last rule of ownership</em></p> When the owner goes out of scope, the value will be dropped.</p> </blockquote> What did we do?</p> We cheated and stored two references of the same memory location (0x147605f70</code>) in two different variables.</li> We prevented Rust from moving the ownership to s2</code> and invalidating s</code>.</li> </ul> As a result, when s</code> and s2</code> go out of scope at the end of the main function, they both think they are the sole owner of the memory they point to and both will try to free that memory!</p> It was an Aha Moment</em> when I realized all that Ownership, Borrowing, values being Copy, and move semantics are just means by which Rust enables memory safety without runtime overhead.</p> That's all I have for you in this blog post.</p> Hope you have experienced an Aha moment</em> by reading this too!</p>

MJ Pooladkhay

my first patch to the linux kernel

2026-03-19T00:00:00+00:00

How an undefined behavior in C made me pull my hair out for days but became my first patch to the Linux kernel!

Intro
Type-2 hypervisor</a>. This approach is similar to how KVM</a> (Linux) or bhyve</a> (FreeBSD) are built.
My experimental hypervisor (and VMM) is still a work-in-progress and is available on my Github: pooladkhay/evmm</a>.
Since virtualization is hardware assisted these days 1</a>, the hypervisor needs to communicate directly with the CPU by running certain privileged instructions; which means a Type-2 hypervisor is essentially a Kernel Module</a> that exposes an API 2</a> to the user-space where a Virtual Machine Monitor (VMM) 3</a> like QEMU</a> or Firecracker</a> is running and orchestrating VMs by utilizing that API.
In this post, I want to describe exactly how I found that bug. But to make it a bit more educational, I'm going to set the stage first and talk about a few core concepts so you can see exactly where the bug emerges.

x86 Task State Segment (TSS)</a> </h2>
4</a>.
This was abandoned in favor of software-defined task switching which gives more granular control and portability to the operating system kernel.
But the TSS was not entirely abandoned. In modern days (64-bit systems) the kernel uses a TSS-per-core approach where the main job of TSS is to hold a few stack pointers that are very critical for the kernel and CPU's normal operation. More specifically, it holds the kernel stack of the current thread which is used when the system wants to switch from user-space to the kernel-space.
It also holds a few known good stacks for critical events like Non-Maskable Interrupts (NMIs) and Double Faults. These are events that if not handled correctly, can cause a triple fault and crash a CPU core or cause an immediate system reboot.
We know that memory access is generally considered to be expensive and caching values somewhere on the CPU die is the preferred approach if possible. This is where the TR register comes into the picture. It has a visible part which is a 16-bit offset that we have already discussed as well as a hidden part that holds direct information about the TSS (Base address, Limit, and Access rights). This saves the CPU the trouble of indexing into the GDT to eventually find the TSS every time it's needed.

Why do hypervisors care?
In a previous blog post 1</a> I described how Intel implemented their virtualization extension (VT-x) and how each vCPU (vCore) is given its own VMCS (Virtual Machine Control Structure) block where its state is saved to or restored from by the hardware when switching between host and guest OSes.
I suggest reading that post if you're interested in the topic but VMCS consists of four main areas:

Host-state area</li>
Guest-state area</li>
Control fields</li>
VM-exit information area</li> </ul>
Host-state area has two fields which correspond to the visible part and one of the hidden parts (base address) the TR register:

`HOST_TR_SELECTOR</code> (16 bits)</li>`
`HOST_TR_BASE</code> (natural width` 5</a>)</li> </ul> While guest-state area has four (one visible plus all three hidden parts): GUEST_TR_SELECTOR</code> (16 bits)</li> GUEST_TR_BASE</code> (natural width 5</a>)</li> GUEST_TR_LIMIT</code> (32 bits)</li> GUEST_TR_ACCESS_RIGHTS</code> (32 bits)</li> </ul> The reason is that the hardware assumes the host OS to be a modern 64-bit operating system where TR limit and Access Rights are fixed known values (0x67</code> and 0x11</code> respectively). But the guest OS can be virtually any operating system with any constraints. Naturally, it is the hypervisor's job to set these values on initial run and to update them when needed (e.g. when the kernel thread that is running a vCPU is migrated to another physical CPU core, the hypervisor must update the host state to match the new core). To set these values, I "borrowed"</a> some code from the linux kernel tree (KVM selftests): vmwrite(HOST_TR_BASE, get_desc64_base((struct desc64 )(get_gdt().address + get_tr())));</code></pre> This piece of code does the following: Gets the address of GDT.</li> Indexes into it using the value of TR register.</li> Parses the TSS segment descriptor and extracts the memory address of TSS.</li> Writes the address into the HOST_TR_BASE</code> section of the VMCS using the special VMWRITE</code> instruction 6</a>.</li> </ul> So far, so good! If for any reason this operation fails to extract and write the correct address, upon the next context switch from user-space to kernel-space (or next NMI or next Double fault), when the CPU hardware tries to read the kernel stack from the TSS to update the Stack Pointer register, it either receives garbage or an unmapped address. Either way, the CPU will eventually face a double fault (a fault that happens when trying to handle another fault like a page fault) and when trying to use one of the known good stacks for handling the double fault, it will fail again which will make it a triple fault and BOOM! The core dies or we get a sudden reboot. Symptoms</a> </h2> Now lets talk about the issue that I was facing. I started developing my hypervisor on a virtualized instance of Fedora, to avoid crashing my machine in case something went wrong. By the time I realized something is indeed wrong, I had already developed the ability to put the CPU in VMX operation, run a hardcoded loop in VMX non-root mode that would use the VMCALL</code></a> instruction to trap into the hypervisor (VMX root) and ask it to print a message, then resume the loop (VMRESUME</code></a>). Additionally, VMCS was programmed to trap external interrupts (e.g. timer ticks). Upon an exit, the hypervisor would check if we (the current kernel thread) needs to be rescheduled, keeping the kernel scheduler happy. I was using preempt notifier api</a> which lets threads provide two custom functions (sched_in</code> and sched_out</code>) that are called by the scheduler when it's about to deschedule the thread as well as right before rescheduling it. These functions are then responsible for cleanups and initialization work that is required. In my case, sched_out</code> would unload the VMCS from the current core, and sched_in</code> would load it on the new core 7</a> while reinitializing it using a series of VMWRITE</code>s 6</a> to match the new core's state. On my virtualized dev environment with only three vCPUs, everything was working just fine. Until I decided to give it a try on my main machine 8</a> where the hypervisor would talk to an actual physical CPU. And BOOM! Seconds after running the loop, the system crashed, in a very unpredictable way. I was logging the core switches and didn't find any meaningful correlation between the last core number and the crash. Additionally, sometimes it would last longer and sometimes it was immediate. After investigating kernel logs a few times, I saw a pattern in the sequence of events that caused the system to eventually hang: The Fatal VM-Exit: An NMI triggered a VM-Exit on CPU 5 and naturally the hardware tried to locate a valid kernel stack from TSS to handle the privilege transition.</li> Core Death: CPU 5 hit a fatal Page Fault attempting to read an unmapped memory address, resulting in a Kernel Oops</a>. CPU 5 was left completely paralyzed with interrupts disabled.</li> IPI Lockup: CPU 6 attempted a routine system-wide update (kernel text patching) requiring an Inter-Processor Interrupt (IPI)</a> acknowledgment from all cores. CPU 6 became permanently stuck in an infinite loop waiting for the dead CPU 5 to respond.</li> Cascading Paralysis: As other cores (3, 8, 11, etc.) attempted standard cross-core communications (like memory map TLB flushes and RCU synchronizations), they too fell into the IPI trap, waiting indefinitely for CPU 5.</li> Terminal State: The RCU subsystem starved, peripheral drivers (like Wi-Fi) crashed from timeouts, and the system entered a total, unrecoverable deadlock.</li> </ul> So why no triple faults?! The Kernel Oops killed the active task and halted operations on CPU 5. However, it left CPU 5 in a "zombie" state. Alive enough to keep the motherboard powered on, but with its interrupts disabled, making it entirely unresponsive to the rest of the system. The quest</a> </h2> Soon I realized that the hypervisor works absolutely fine 9</a> when pinned to one core (e.g. via taskset</code></a> command), so there must be something happening while moving between cores. Additionally, I didn't dare to question the code I stole from the Linux kernel source, and I was trying hard to find an issue in the code I wrote myself. This eventually led to rewriting a portion of the hypervisor code with an alternative method which would achieve the same goal. For example, from reading Intel's Software Developer Manual (SDM) 10</a>, I knew that when moving from core A to core B, core A must run the VMCLEAR</code></a> instruction to unload the VMCS, and only then can core B load the VMCS using the VMPTRLD</code></a> to be able to execute the guest code. For that, I was using smp_call_function_single</code> which relies on IPI</a>s to run a piece of code on another CPU, that I replaced with the preempt notifiers. Eventually, (while pulling my hair out) I realized I have eliminated all possible parts of the hypervisor that played a role in moving between cores. Then there was another clue! While running the hypervisor on my virtual dev environment (QEMU + Fedora) I observed that by increasing the number of vCores, I can reproduce the issue and there is also a new behavior. Sometimes the VM reboots immediately (instead of freezing) and after the reboot, there is no trace of any logs related to the previous session. And I concluded that a triple fault has happened. This turned my attention to the TR and TSS. I started looking for alternative ways of setting the HOST_TR_BASE</code> and realized that the KVM itself (not KVM selftests) uses a different method</a>: / * Linux uses per-cpu TSS and GDT, so set these when switching * processors. See 22.2.4. / vmcs_writel(HOST_TR_BASE, (unsigned long)&get_cpu_entry_area(cpu)->tss.x86_tss);</code></pre> And that was it! Using this method to set HOST_TR_BASE</code> fixed my hypervisor and helped me keep whatever sanity I had left. The smoking gun</a> </h2> Remember that piece of code I took from the kernel source. It used the get_desc64_base</code> function to extract and write the address of TSS into the HOST_TR_BASE</code>. This function has this definition: static inline uint64_t get_desc64_base(const struct desc64 desc) { return ((uint64_t)desc->base3 << 32) | (desc->base0 | ((desc->base1) << 16) | ((desc->base2) << 24)); }</code></pre> TSS segment descriptor has four fields that must be stitched together to form the address of the TSS 11</a>. base0</code> is uint16_t</code>.</li> base1</code> is uint8_t</code>.</li> base2</code> is uint8_t</code>.</li> base3</code> is uint32_t</code>.</li> </ul> The C standard 12</a> dictates Integer Promotion. Whenever a type smaller than an int</code> is used in an expression, the compiler automatically promotes it to a standard int</code> (which is a 32-bit signed integer on modern x86-64 architectures) before performing the operation. If an int</code> can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int</code>; otherwise, it is converted to an unsigned int</code>. These are called the integer promotions. All other types are unchanged by the integer promotions. </div> — Section 6.3.1.1 </div> </blockquote> This promotion has a consequence: (see the Update</a> section) if the resulting value after promotion has a 1</code> in its most significant bit (32nd bit), this value considered negative by the compiler and if casted to a larger type like a uint64_t</code> in our case, sign extension happens.</del> Lets see an example: We have an 8-bit unsigned integer (uint8_t</code>) with 11001100</code> bit pattern. If we left-shift it by 24, it still can be represented by an int</code> which is 32 bits long. So the compiler generates this value: 11001100000000000000000000000000</code> and considers it to be an int</code> which is a signed type. Now if we try to perform any operation on this value, it would follow the protocol for signed values. In our case, we are OR</code>ing it with a uint64_t</code>. So the compiler would cast our int</code> (a 32-bit signed value) into uint64_t</code> (a 64-bit unsigned value), which is where the sign-extension happens which would turn our value to 11111111111111111111111111111111_11001100000000000000000000000000</code> before OR</code> happens. Saw the problem? Because the upper 32 bits are sign-extended to all 1</code>s (Hex: 0xFFFFFFFF</code>), the bitwise OR</code> operation completely destroys base3</code> (In a bitwise OR</code>, 1 | X</code> equals 1</code>). Therefore, whatever data was in base3</code> is permanently overwritten by the 1</code>s from the sign extension. Here is an actual example with "real" addresses: base0 = 0x5000 base1 = 0xd6 base2 = 0xf8 base3 = 0xfffffe7c Expected return: 0xfffffe7cf8d65000 Actual return: 0xfffffffff8d65000</code></pre> This also explains when the problem would happen: Only and only if base2</code> has a 1</code> as its most significant bit. Any other value would not corrupt the resulting address. The Kernel patch</a> </h2> The fix is actually very simple. We must cast values to unsigned types before the bit-shift operation: static inline uint64_t get_desc64_base(const struct desc64 *desc) { return (uint64_t)desc->base3 << 32 | (uint64_t)desc->base2 << 24 | (uint64_t)desc->base1 << 16 | (uint64_t)desc->base0; }</code></pre> This will prevent the sign-extension from happening. Finally, this is the patch I sent, which was approved and merged: https://lore.kernel.org/kvm/20251222174207.107331-1-mj@pooladkhay.com/</a> Outro</a> </h2> I would say the main takeaway is to never trust any code. Kernel developers are also human (at least for now) which leads me to a quick note on AI! You may wonder whether I tried asking an LLM for help or not. Well, I did. In fact it was very helpful in some tasks like summarizing kernel logs and extracting the gist of them. But when it came to debugging based on all the clues that were available, it concluded that my code didn't have any bugs, and that the CPU hardware was faulty. CASE CLOSED. Update</a> </h2> After this post made its way to Hacker News</a>, fonheponho</code> pointed out a crucial flaw in my root cause analysis. While the patch correctly fixes the bug, I blamed the wrong part of the C standard for the crash. The issue isn't "sign extension" during the cast to uint64_t</code> 13</a>. The real issue is an Undefined Behavior (UB)</a> triggered by an invalid bitwise left-shift, one step earlier. Here is the correct sequence of events: Integer promotion: Just as I mentioned, desc->base2</code> (a uint8_t</code>) is promoted to a signed int</code>, because int</code> can represent all values of an 8-bit unsigned integer. </li> The illegal shift: The C standard's rules for E1 << E2</code> state that if E1</code> has a signed type and a non-negative value, the result is valid only if $E1 \times 2^{E2}$ is representable in the result type. If it isn't (as is the case when we shift a 1</code> into the sign bit of a 32-bit int</code>) the behavior is undefined. The UB happens here, inside the shift itself, before any cast occurs. </li> The manifestation: With UB already invoked, the C standard makes no guarantees about what follows. The "sign extension" I described, where the upper 32 bits become all 1</code>s during the subsequent cast to uint64_t</code>, is simply what GCC on x86 produces, probably because the underlying SHL</code> instruction naturally yields that bit pattern and the compiler inserts no special handling. A different compiler, or even a different optimization level, could have produced something else entirely. </li> </ol> The fix remains exactly the same: casting desc->base2</code> to uint64_t</code> before the shift forces the operation onto an unsigned 64-bit integer, where the shift is well-defined and no bits are lost. Thanks to the HN community for keeping me technically honest! ^1Check out my previous post for more details: virtualization: theory to silicon</a> </div> ^2KVM API documentation: https://docs.kernel.org/virt/kvm/api.html</a> </div> ^{3 Hypervisor and Virtual Machine Monitor (VMM) are generally interchangeable terms, while some might differentiate them slightly (e.g. VMM as user-space part of a kernel-space hypervisor). </div>}^{4 TR register does not directly point to TSS. It holds an offset that is used to index into a region of memory called the Global Descriptor Table (GDT). This offset is where the TSS segment descriptor lives, and is the entity that actually holds the address of the TSS. At this point I hope you're asking "WTF Intel?!" Well, these design decisions were made back in the 80s where memory was scarce, paging hadn't been fully adopted yet, and segmentation was "the way" of managing memory and privilege levels. </div>}^{5 32 bits on 32-bit machines and 64 bits on 64-bit machines. </div>}^6It's not possible to write to and read from the VMCS using usual memory read and write operations. There are special instructions to do so: VMREAD</code></a> and VMWRITE</code></a>. </div> ^{7 Yes, this path must be optimized since this loading and unloading is relatively heavy. And hypervisors usually pin threads to cores to avoid paying this fee. </div>}^{8 It's an Intel Core i7-12700H with 14 Cores (6 Performance, 8 Efficient) and a total of 20 threads. </div>}^{9 Looking back, that was purely luck. Continue reading to know why... </div>}^10Volume 3C of the SDM</a> covers the virtual machine extension (VMX). </div> ^{11 Another remnant of old hardware design that is kept for backward compatibility purposes, but "WTF Intel?!" indeed. </div>}^12https://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf</a> </div> ^{13 Sign-extension is an ISA concept, not a C one. </div>}

virtualization: theory to silicon 2025-11-20T00:00:00+00:00 A description of the modern virtualization; starting from Popek and Goldberg and getting all the way to the implementation of the Intel VT-x (VMX) extension. Intro</a> </h2> It's not a stretch to claim that virtualization is the technology that makes the modern digital world possible! According to Wikipedia</a>: Virtualization (abbreviated v12n) is a series of technologies that allows dividing of physical computing resources into a series of virtual machines, operating systems, processes or containers. </div> </blockquote> Unless you are reading a printed copy of this post, you are already using and benefiting from some form of virtualization. The operating system on your device virtualizes CPU and memory, making them available to processes like your web browser and giving each the illusion that it owns and controls the entire hardware. This abstraction also isolates processes so they cannot interfere with one another. If you use public cloud services such as Google Cloud or AWS, virtualization plays an even more prominent role. The classic example is a Virtual Machine (VM) instance, but in practice, nearly all serverless and managed services are also backed by VMs which are isolated, fully featured operating system instances that share the same underlying hardware. This blog post focuses on full hardware virtualization (the technology that gives rise to VMs), by drawing some historical context, then giving an intuitive explanation of the theory behind it, and finally how Intel turned a non-classically-virtualizable architecture into a virtualizable one. Historical context</a> </h2> In the dawn of computing, time-sharing and virtualization realized to be practical solutions to three critical needs: System utilization: making expensive computers more cost-effective by sharing them,</li> Isolation: preventing interference between users,</li> Security: allowing users with different clearance levels to work on the same machine.</li> </ul> Compatibility was another issue, and a famous example is IBM System/360</a> which was an attempt to merge various incompatible lines of business and scientific-oriented machines into a single family of computers. That eventually led to IBM System/360 Model 67</a> along with its hypervisor and operating system CP/CMS</a>. CP, the Control Program, created the virtual machine environment and provided each user with a simulated stand-alone System/360 computer. And CMS, the Cambridge Monitor System 1</a> was a lightweight single-user operating system, that ran on top of CP's virtual machines. This allowed a great number of simultaneous users to share a single physical S/360 machine. And bear in mind that we are talking about 1960s! Now we are in this era where some systems support virtualization natively and some don't. For a few organizations - the U.S. Air Force and the Atomic Energy Commission to be more specific - this was of high importance which was why they were funding research to find a new, verifiable way to build secure systems. In 1974 Gerald J. Popek and Robert P. Goldberg published a seminal paper</a> on Formal Requirements for Virtualizable Third Generation 2</a> Architectures, with this abstract: Virtual machine systems have been implemented on a limited number of third generation computer systems, e.g. CP-67 on the IBM 360/67. From previous empirical studies, it is known that certain third generation computer systems, e.g. the DEC PDP-10, cannot support a virtual machine system. In this paper, model of a third-generation-like computer system is developed. Formal techniques are used to derive precise sufficient conditions to test whether such an architecture can support virtual machines. </div> — Gerald J. Popek and Robert P. Goldberg </div> </blockquote> Theory</a> </h2> Popek and Goldberg define a Virtual Machine to be an efficient, isolated duplicate of the real machine and they explain these notions through the idea of a Virtual Machine Monitor (VMM). The VMM software has three main characteristics: To provide an essentially identical environment to the guests. This excludes resource availability such as amount of memory and timing requirements due to the intervening level of software and because of the effect of any other virtual machines concurrently existing on the same hardware.</li> To be efficient, meaning that a statistically dominant subset of the virtual processor's instructions must be executed directly by the real processor, with no software intervention by the VMM. This statement rules out traditional emulators and complete software interpreters (simulators) from the virtual machine umbrella.</li> To have control over the system resources in such a way that it is not possible for a program running under VMM in the created environment to access any resource not explicitly allocated to it, and it is possible for the VMM to regain control of resources already allocated.</li> </ol> The model</a> </h3> Then they define a simplified version of a third-generation machine as a 4-tuple while assuming that I/O instructions and interrupts don't exist 3</a>: $S = (E, M, P, R)$ $S$ represents the current state of the real machine (not a virtual machine).</li> $E$ (Executable storage) represents the contents of the machine's memory (RAM).</li> $M$ (Mode) represents the two possible modes of operation in this model: Supervisor and User.</li> $P$ (Program counter) is a register that holds the memory address of the next instruction to be executed.</li> $R$ (Relocation-bounds register) represents the set of privileged registers that define the current accessible address space. They control which parts of the memory ($E$) the program (virtual OS) is allowed to see and modify. In modern terms, this would be registers and that hold page table information (e.g. CR3 register on x86, and segment registers when executing in protected mode).</li> </ul> Describing an abstracted model of a machine is a very powerful tool in the sense that it lets us reason about the behavior of the machine without needing to know the exact state of the hardware or the actual physical implementation. Instructions</a> </h3> In this model, instructions act on the state of the machine transitioning it from one state to another one, and live under one of three main categories: Privileged instructions: Any instruction that traps 4</a> to the Supervisor mode when executed in the User mode. </li> Sensitive instructions Control sensitive: Any instruction that when executed, changes the mode ($M$) of the processor or the value of the Relocation-bounds register ($R$) or both. Intuitively, we can think of the control sensitive group as instructions that change the privileged state of the processor or write to some memory location that is not allocated to them. An example is LIDT</code> instruction on x86 that changes the value of the interrupt descriptor table register.</li> Behavior sensitive: Any instruction that the effect of its execution depends on the mode ($M$) of the processor or on the value of the Relocation-bounds register ($R$) or both. We can think of them as instructions that reveal the privileged state of the processor or read from a memory location that is not allocated to them. An example is SIDR</code> instruction on x86 which can be used to reveal the interrupt descriptor table base address and limit.</li> </ul> </li> Innocuous instructions: Any instruction that is neither Privileged nor Sensitive. </li> </ul> This categorization helps with reasoning about the effect(s) of executing a given instruction. Main Theorem</a> </h3> Now that we are familiar with the model of the machine and various types of instructions, we are ready to get to the actual requirement for virtualization: For any conventional third generation computer, a virtual machine monitor (VMM) may be constructed if the set of sensitive instructions for that computer is a subset of the set of privileged instructions. </div> — Theorem 1 </div> </blockquote> Intuitively, this means that we can build and run a classic VMM 5</a> on any machine where all sensitive instructions are privileged, i.e. executing them would trap and transfer control back to the VMM. This simple but foundational rule ensures that guests cannot access or modify the state of the VMM or other guests on the machine, and are bound to the resources that were specifically allocated to them. But what about efficiency? I'm glad you asked! To be efficient, the requirement is that all Innocuous instructions which are the majority of instructions, be executed directly on the CPU without any traps or interventions from the VMM. If a machine satisfies these rules, we can build an efficient VMM such that guests run in an essentially identical environment to the host while the VMM maintains control over the system resources. Practice</a> </h2> The x86 instruction set architecture contains 18 instructions that are sensitive but not privileged 6</a>. As a result, based on the Popek and Goldberg's work, it's not possible to build an efficient classic 5</a> VMM for it. Rings of power</a> </h3> Before getting into the solution, lets make sure we're all on the same page regarding the x86 protection rings and how CPU operates from that perspective. The architecture defines four protection rings: 0, 1, 2, and 3. Ring 0 is the most and Ring 3 is the least privileged. Modern operating systems only use Ring 0 and 3, where the OS kernel runs in Ring 0 and user-space programs run in Ring 3. To be able to run multiple operating systems on a x86 CPU, all four Rings must be virtualized so that the resulting environment is identical to the physical hardware. You may ask why can't we just run the host kernel in Ring 0 and guest kernel(s) on a lower Ring like 1 and call it a day?! Well, that's a valid question but it's not that simple! x86 is in trouble</a> </h3> In reality, a few of the non-privileged sensitive instruction do become privileged in rings lower that 0, which is what we want, but some of them still don't behave! And again we are left with sensitive instructions that are not privileged, hence the architecture doesn't satisfy Popek and Goldberg's requirements, even in lower rings. An example is the POPF</code></a> which is a Control sensitive instruction that pops the top of stack into the FLAGS</a> register. OS kernels use this instruction regularly but it silently fails (updates math flags e.g. ZF, but ignores interrupt flag) when executed in a Ring lower than 0. To better illustrate the problem, lets also consider these three instructions that you might already be familiar with: SGDT</code></a>, SIDT</code></a>, and SLDT</code></a>. If the OS in a VM (virtual OS) uses SGDT</code>, SLDT</code>, or SIDT</code> to reference the contents of the GDTR (Global Descriptor Table Register), LDTR (Local Descriptor Table Register), or IDTR (Interrupt Descriptor Table Register) the register contents that are applicable to the host OS, VMM, or another virtual OS will be revealed. This could cause a problem if the virtual OS tries to use these values for its own operations. Therefore, each virtual OS must be provided with a separate set of IDTR, LDTR, and GDTR registers. Unfortunately, in practice, it's not possible to have dedicated sensitive registers per virtual OS. This would mean that the CPU die must physically include these registers, which would translate into having a hard limit on the number of VMs a given CPU can support, as well as making each CPU way more expensive. But fear not my child 7</a> as there is a better solution! What if we stayed at Ring 0 where kernels expect to find themselves, but made all sensitive instructions privileged? (And I hope you’re asking: "But if the kernel is already in Ring 0, where would it trap to?") Enter VT-x extension</a> </h3> In 2005</a>, with the launch of two Pentium 4 models (662 and 672) Intel announced the VT-x (VMX) extension. When software enables the extension by executing the VMXON</code></a> instruction, CPU enters the "VMX Root" mode. From an operational point of view, it is almost identical to how the CPU was operating before, but it introduces a new, orthogonal state: "VMX Non-Root" mode. In the VMX Non-Root mode, the virtualization holes are plugged: Sensitive instructions become privileged and trigger traps, while the Guest OS still has full access to the four protection rings, letting it run in Ring 0 and run its user-space programs in Ring 3 as it would normally do. In this mode, instructions that would cause a user-space program to trap into the kernel (Ring 3 to 0) e.g. SYSCALL</code></a>, still behave the same way, but executing a sensitive instructions would trap into the VMX Root mode and transfer control back to the VMM/hypervisor. And with that, the architecture now conforms to the Main Theorem</a>! VMCS (the leash)</a> </h3> In the x86 is in trouble</a> section we concluded that each virtual operating system must be provided with a separate set of sensitive registers to operate independently, and that it's not feasible to have these registers baked into the silicon. To facilitate that, Intel introduced the notion of VMCS (Virtual Machine Control Structure) that is a region of memory allocated by the hypervisor before entering VMX non-root mode. VMCS consists of four main areas: Host-state area</li> Guest-state area</li> Control fields</li> VM-exit information area</li> </ul> The idea is relatively simple: Prior to entering the VMX non-root mode, hypervisor saves the current state of the CPU in the Host-state area, loads the desired state of the guest into the Guest-state area, and finally defines the expected behavior for the CPU while in non-root mode (e.g. which instructions or events should cause a switch to the VMX root mode) into the Control fields of the VMCS. When exiting from non-root to root mode, the guest state is saved back to the VMCS, host state is loaded into the CPU registers, and the reason of exit is written into the VM-exit information area. The exit information is later used by the hypervisor to decide what would be the next appropriate action to take before switching back to the guest. By allocating a VMCS per virtual CPU (vCPU), the hypervisor controls/virtualizes the physical CPU, making it possible to run multiple operating systems in isolation and giving each the illusion that they have a few dedicated CPU cores, while operating on a limited number of actual physical cores 8</a>. Outro</a> </h2> All other major CPU vendors have implemented the same theory and concepts but in slightly different ways. AMD has AMD-V, Arm has EL2, and RISC-V has H-extension. Every tool and piece of technology that we take for granted today, didn't appear over night. Yes, sometimes it was an accidental discovery but most of the times it's about people who were trying to solve a specific problem that eventually came up with an idea. Further more, original ideas are a lot simpler than the complexity we observe today, since they don't include years and years of time and effort that has refined and reshaped them. Personally, I have always found the history and theory behind a tool way more interesting than the tool itself. It gives me the ability to see the beauty and simplicity behind the idea and not to get overwhelmed by the current complex state of it, which ultimately translates into being able to easily understand and reason about it. Hopefully, next time a Cloud provider asks you to choose the number of vCPUs for a VM, you have a better idea of what's going on under the hood. Further reading</a> </h2> Virtual Machines</a> by Jim Smith and Ravi Nair. ^1also Console Monitor System but eventually renamed to Conversational Monitor System</a>. </div> ^2More</a> about third generation of computers. </div> ^3Formal virtualization requirements for the ARM architecture</a> published in 2013 builds on Popek and Goldberg's work and extends their machine model to modern architectures with paged virtual memory, I/O and interrupts. </div> ^{4 When a trap happens, the processor automatically saves the current state of the machine and passes the control to a pre-specified routine by changing the processor mode, the relocation-bounds register, and the program counter. </div>}^{5 I say classic because some machines, like the PDP-10, are not classically virtualizable. However, based on Popek and Goldberg’s second theorem, a hybrid virtual machine monitor (HVM) can still be constructed for them under another set of constraints. Additionally, there are other methods like binary translation where the VMM intercepts and rewrites guest OS code at runtime which are beyond the scope of this post. </div>}^6"Analysis of the Intel Pentium's Ability to Support a Secure Virtual Machine Monitor"</a> by John Scott Robin and Cynthia E. Irvine. </div> ^{7 I'm not really your father, sorry for disappointing you and for the tacky humor. </div> ^{8 This concept is very similar to how an operating system internally switches between multiple processes. The main difference is that an operating system does the virtualizes at Ring 3 (user-space), while hypervisors virtualize all four rings with some help form the hardware itself. </div>}} programming is modeling - an experience report 2024-07-11T00:00:00+00:00 A short description of why mental models are important when building systems. Intro</a> </h2> A CLI game is basically a state-machine with a loop that continuously checks and updates the state based on some criteria such as user input or when a collision happens. A while ago I built such a game, HEXvaders</a>, where, not surprisingly, I had to dynamically print characters to the terminal screen. Later I decided to let multiple players compete online by splitting the screen such that the game occupies two-thirds of the screen, with the remaining one-third dedicated to a scoreboard. Soon I realized that in order to split the screen to add a scoreboard, I need to refactor the entire codebase, and if you need to refactor an entire idea to add another piece of functionality, chances are something is fundamentally wrong with how you modeled the idea in the first place. There are libraries out there to create Terminal UIs but since I like re-inventing the wheel, I went to the quest of creating a library that I can use to reimplement my game, with extendibility in mind. In this blog post I want to briefly discuss how I initially designed the game, how I did it the second time and what I learned from it. First attempt</a> </h2> A game has some objects, like arrows, enemies, cars, etc. that needs to keep track of. In case of my game, each item on the screen can be considered an object, e.g. the game canvas, input area, an invader, an arrow, etc. In the first try, one major flaw in my design was the way I separated the concerns, or in other words, the way I didn't separate the concerns! The idea behind the HEXvaders is simple, when you see a hexadecimal value on the screen, an invader, enter the binary equivalent of the hex value to kill the invader! In particular, the fundamental issues in my first design were as follows: There was no holistic view of the world, i.e. there was no entity knowing the position of all objects in order to find and correct any potential drifts.</li> Each game object (i.e. invader, arrow, bottom board, etc.) was responsible for drawing itself to the screen by calling print!()</code>, in addition to saving the its own state.</li> Printing to the screen was being done character by character, by calling to print!()</code>, and since I/O is relatively expensive this causes a performance issue.</li> </ul> Second attempt</a> </h2> While working on the game, I also realized each game object can be considered to be either a rectangle or a text, hence the rectext library</a> (repo is not public yet) was born! My goal was to address the issues with the first design, I wanted a library to handle the positioning and drawing of characters so that I can focus the the game logic itself. Characteristics of the rectext library: It has an internal buffer which is simply a Vector of bytes that stores the characters based on their position/coordinate on the screen.</li> It exposes two main types for creating more complicated objects, Rectangle</code> and Text</code>.</li> Since I used Rust, it exposes a trait called UIElement</code>. Any object that implements this trait can be passed to the library to be printed on the screen.</li> It has a Terminal</code> object that knows how to talk to an ANSI Terminal.</li> In has a rendering algorithm that generates the next "frame", considering what is the current state of the screen and what should be the next state. For that, it uses a double-buffering strategy.</li> For each frame, there is only one call to print!()</code>, as a result each frame gets printed to the screen in one shot.</li> The library accepts arbitrary entities as stdin</code> (if it implements AsRawFd + Read</code> traits) and stdout</code> (if it implements AsRawFd + Write</code> traits), with the goal of making it easy to port it to WebAssembly.</li> </ul> With this new way of modeling my idea, what I built is a library that given a set of objects with their coordinates, generates a string of characters to be interpreted by a terminal. This is similar to how a compiler transforms one representation of a program to another. With the right mental model of the problem, once an almost impossible task, became as easy as a pie! Here is when the game starts at position (0, 0)</code> and fits the entire screen: let game = Game::new(0, 0, (screen_cols).into(), (screen_rows).into());</code></pre> And this is when the game starts at position (0, 0)</code> and only occupies two-thirds of the screen: let game = Game::new(0, 0, (screen_cols * 2 / 3).into(), (screen_rows).into());</code></pre> Now you should be able to imagine the endless possibilities of various arrangements of the objects on the screen. Conclusion</a> </h2> This blog post was not about teaching you about specifics of Rust nor about how one should design a UI library. My goal was to remind you that having the correct model in mind is very critical when it comes to designing software. Thinking about how different parts of the code would interact with each other, and thinking about how to model them is a crucial aspect of every software project. I would like to end this with a quote from Rob Pike, on the importance of mental models and how he learned this from Ken Thompson: A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about how that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model. Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs. I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software. </div> — Rob Pike </div> </blockquote> it’s all about memory 2024-06-28T00:00:00+00:00 A comparison of memory management in C vs. Rust. Intro</a> </h2> When talking about memory, it's always good to remind ourselves that we have the Stack and the Heap. Stack is pretty straightforward, while Heap is its own beast. In fact, the word memory in "memory management" almost always refers to the Heap memory. In C, the programmer is in charge of allocating and deallocating the memory which is proven to be very powerful and very dangerous at the same time, leading to in issues like double-free</a>, use-after-free</a> or even using a pointer before initialization, causing Wild Pointers</a>! (again) In C, it's completely legal to request a piece of memory (e.g. via malloc</code>) and then give out multiple copies of the address of that memory. Ignoring the possible data races that may occur, this also raises more serious questions: Who is in charge of freeing (deallocating) the memory when the program no longer needs it?</li> When it's freed, how can we ensure there won't be another attempt to free that memory again? (remember there are multiple copies of that address out in the wild!)</li> Last but not least, how can we ensure that no one will attempt to access that memory after it’s been freed?</li> </ul> Those are the types of questions/issues that Rust is trying to solve with its niche way of managing memory. First, we'll see a simple program in C that deals with memory allocation and deallocation, and later we will try to rewrite the same program in Rust and see how those two compare. in C</a> </h2> Let's start with C: 1// #1 2// main.c 3// start... 4 5#include <stdio.h> 6#include <stdlib.h> 7 8int main(int argc, char const *argv[]) 9{ 10 11 int *s = (int *)malloc(sizeof(int)); 12 // ...checking if malloc succeeded... 13 14 // Assigning the value 1 to the memory 15 // location pointed to by `s` 16 *s = 1; 17 18 // `=` performs a bitwise copy 19 int *s2 = s; 20</code></pre> The =</code> operator performs an assignment, and the type of assignment depends on the type of the variables involved. For primitive data types (integers, floating-point numbers, etc.), the =</code> operator performs a bitwise copy. It copies the binary representation of the value from the right-hand side to the variable on the left-hand side (like memcpy()</code>). It would be fine if the value of s</code> was an ordinary int</code> or a float</code> living on the Stack. But since both s</code> and s2</code> are pointers, and pointers are inherently unsigned integers, the =</code> operator would perform a bitwise copy as if the value was an ordinary integer! After the assignment, both s</code> and s2</code> would have the same value which is the address of an int</code> value on the Heap. The memory allocated by calling to malloc()</code> could potentially be deallocated by calling free()</code> on both s</code> and s2</code>. Let's say free(s)</code> was called. Now there is no way for the user of s2</code> (which could be another thread or another function on the same thread) to realize that this variable should neither be freed nor used anymore. Although this might seem like the kind of issue that could be easily prevented by the programmers being careful enough, time has proven that is not always the case, and big contributor to serious security bugs are still memory safety problems. According to a blog post by CISA</a>: Microsoft reported that “~70% of the vulnerabilities Microsoft assigns a CVE [Common Vulnerability and Exposure] each year continue to be memory safety issues.” Google likewise reported that “the Chromium project finds that around 70% of our serious security bugs are memory safety problems.” Mozilla reports that in an analysis of security vulnerabilities, that “of the 34 critical/high bugs, 32 were memory-related.” </blockquote> Addresses</a> </h3> Let's print out some memory addresses and values to better understand what is where and where is what: 21// #2 22// main.c 23 24 // Addresses of `s` and `s2` on the Stack 25 printf("%p\n", &s); // 0x16b446fc8 26 printf("%p\n", &s2); // 0x16b446fc0 27</code></pre> Now let's print out the values that are stored in s</code> and s2</code>: 28// #3 29// main.c 30 31 // Values directly stored in `s` and `s2` 32 printf("%p\n", s); // 0x14fe060e0 33 printf("%p\n", s2); // 0x14fe060e0</code></pre> Both store the same values, the address of a memory location on the heap. Values and UB</a> </h3> Finally, let's print the values stored at the location to which s</code> and s2</code> are pointing, which is obviously 1</code>. Additionally, it's completely legal to free a memory location and try to access it again, which is considered Undefined Behaviour (UB). 34// #4 35// main.c 36 37 // Actual values stored on the heap 38 printf("%d\n", *s); // 1 39 printf("%d\n", *s2); // 1 40 41 free(s); 42 43 // At this point both `s` and `s2` are considered "dangling pointers" 44 45 printf("%d\n", *s); // Undefined Behaviour (UB) 46 printf("%d\n", *s2); // UB 47 48 return 0; 49} 50 51// end of main.c</code></pre>Memory Layout</a> </h3> Here is a diagram to visually see how things are laid out in the memory. Stack usually uses higher addresses than heap, and grows downward. Variable</th> Memory Address</th> Value</th></tr></thead> ...</td> ...</td> ...</td></tr> s</td> 0x16b446fc8</td> 0x14fe060e0</td></tr> s2</td> 0x16b446fc0</td> 0x14fe060e0</td></tr> ...</td> ...</td> ...</td></tr> ...</td> ...</td> ...</td></tr> </td> 0x14fe060e0</td> 1</td></tr> ...</td> ...</td> ...</td></tr> </tbody></table> in Rust we trust</a> </h2> Rust has a very interesting way of managing memory. Essentially, each value has an owner who is responsible for clearing the memory location where the value is stored (i.e. giving back the memory to the OS) when it's no longer required. Each value can only have one owner who is responsible for cleaning up the memory acquired by the values. According to the Rust Book, there are three rules of ownership: Each value in Rust has an owner.</li> There can only be one owner at a time.</li> When the owner goes out of scope, the value will be dropped.</li> </ul> Then, there is borrowing which has its own set of rules: At any given time, you can have either one mutable reference or any number of immutable references to a value.</li> References must always be valid.</li> </ul> The last point in the borrowing rules ensures that there are no references to a value (either mutable or immutable) lingering around after the value has been dropped (i.e., the memory location for the value has been deallocated/freed), hence no dangling pointers! We have already seen that this is not the case with C. I'm not going to dive more into this topic since it deserves its own series of posts. However, I encourage you to refer to the official Rust Book's chapter on Ownership and Borrowing</a>. Boxing</a> </h3> Let's rewrite the same program in Rust which claims to be a memory-safe programming language. Spoiler Alert, It's not possible!! At least not with the "safe" side of Rust, as we will see shortly. This time, we're going to slightly rearrange the code. First, we create s</code>, print out different aspects of it, and then try to create s2</code> and do the same: 1// #5 2// main.rs 3 4fn main() { 5 let s = Box::new(1_i32); 6 7 // Address of `s` on the Stack 8 println!("{:p}", &s); // 0x16af1e9d8 9 10 // Value stored directly in `s` 11 println!("{:p}", s); // 0x153e05f70 12 13 // Actual value stored on the heap 14 println!("{}", s); // 1 15 16 let s2 = s; 17 18 // Address of `s2` on the Stack 19 println!("{:p}", &s2); // 0x16af1e9e0 20 21 // Value stored directly in `s2` 22 println!("{:p}", s2); // 0x153e05f70 23 24 // Actual value stored on the heap 25 println!("{}", s2); // 1 26}</code></pre> The Box</code> is referred to as a Smart Pointer and serves as Rust's mechanism for allocating memory on the heap. The signature of the Box::new()</code> function is pub fn new(x: T) -> Self</code>. Essentially, it accepts an arbitrary value of type T</code> and returns a Box<T></code>. This can be interpreted as a pointer to some location on the heap, similar to what malloc</code> did in C but with less effort and greater control and safety. And that kind-of-weird-looking 1_i32</code> is just the number 1</code> represented in a 32-bit signed integer type. So far, so good! nothing particularly interesting is happening in this program. It compiles and runs perfectly fine. If you're interested in reading more about the Smart Pointers, please refer to the official Rust Book's chapter on Smart Pointers</a>. Moving</a> </h3> Now let's rearrange the code similar to the C one: 1// #6 2// main.rs 3 4fn main() { 5 let s = Box::new(1_i32); 6 let s2 = s; 7 8 // Addresses of `s` and `s2` on the Stack 9 println!("{:p}", &s); 10 println!("{:p}", &s2); 11 12 // Values directly stored in `s` and `s2` 13 println!("{:p}", s); 14 println!("{:p}", s2); 15 16 // Actual values stored on the heap 17 println!("{}", s); 18 println!("{}", s2); 19}</code></pre> See that? I didn't add the result of the println!()</code> macros in front of them because this code doesn't compile! Here is the compiler's error: | 5 | let s = Box::new(1_i32); | - move occurs because `s` has type `Box<i32>`, which does not implement the Copy trait 6 | let s2 = s; | - value moved here … 9 | println!("{:p}", &s); | ^^ value borrowed here after move | help: consider cloning the value if the performance cost is acceptable | 6 | let s2 = s.clone(); | ++++++++</code></pre> Interesting! Why did it worked in the code snippet number #5</code>? Keep reading! Copy and Clone</a> </h3> Do you remember the first two ownership rules? When the Box::new()</code> allocates a location on the heap and returns a pointer to it, the variable s</code> becomes the owner of that piece of memory. Deallocation happens when the owner goes out of scope; in this case, the scope ends at the end of the main</code> function. This ensures that the memory gets freed automatically, without the need to manually call a free()</code>-like function, when it's no longer required. By assigning s</code> to s2</code>, we are moving the ownership of the memory location pointed to by s</code>, to s2</code>, and since there can only be one owner at a time, after the assignment operation, s</code> is no longer valid. If we were to assign just the number 1</code> to s</code> (let s = 1_i32</code>), then the value would be stored on the stack, and when assigning s</code> to s2</code>, s2</code> would receive a fresh "Copy" of the value 1</code>, which is again stored on the stack and is completely unrelated to the value stored in s</code>. In Rust, Primitive types like integers and booleans are "Copy" which means they implement the Copy</code> trait, which means they can be copied around easily and, most importantly, cheaply. Moving the ownership only happens to the variables that are storing a non-copy value. Although pointers are still numbers, in contrast to C, Rust treats them differently. In fact, Rust calls them References instead of Pointers. Rust also has Pointers (a.k.a. "Raw Pointers"), which pretty much behave like what you would expect from a pointer in C, where there is no notion of Ownership and Borrowing. Raw Pointers cannot be used in "Safe Rust" and are used in scenarios like Foreign Function Interface (FFI)</a>. It is also possible to make a "fresh copy" of a value stored on the heap. But in doing so, first, we need to allocate the required memory and then copy the value over. Memory allocations are considered to be costly operations; in general, we usually use heap memory to store values whose size is not known at compile time or values whose lifetime should cross function-call boundaries. If a type is Copy</code>, by assigning it to another variable, the new variable would receive a bitwise copy of the old value and would become the owner of the new copy as well; and if the value doesn't implement the Copy</code> trait, the ownership of the old value would be moved over to the new variable and the old variable can no longer be used. Unless the programmer explicitly calls clone()</code>, which usually would cause an allocation to happen for the new value on the heap. On the other hand, if a value is Copy</code>, then calling clone()</code> would do nothing more than the implicit copy. As a result, in Rust, Copying is an implicit operation, while Cloning is always explicit. Additionally, the implementation of Clone</code> can vary for different types based on their specific needs. More information about Copy</code> and Clone</code> can be found here</a>. Compiler-Driven Development (CDD)</a> </h3> Now we can also understand the help message: consider cloning the value if the performance cost is acceptable.</code> In Rust, the compiler is your best friend! So, with more theory behind us, we are hopefully more comfortable making sense of the compiler's messages. Being able to understand why the compiler is yelling at us is a crucial skill to develop while learning Rust. Before continuing with more code, one last point is to understand why the first program, where the order of variable definition/assignments and println!()</code>s were different, worked. That was because we didn't try to use the variable s</code> after its value moved to s2</code>, and the compiler was smart enough to realize that. Isn't that cool?! The lifetime of s</code> ends after the move, and it should no longer be used, which was exactly what we did in the first Rust example. It's time to make our compiler friend happy again without rearranging the order of operations. Borrowing</a> </h3> For that, we are going to borrow the value of s</code>. By doing so, s</code> would remain the owner: 1// #7 2// main.rs 3 4fn main() { 5 let s = Box::new(1_i32); 6 let s2 = &s; 7 8 // Addresses of `s` and `s2` on the Stack 9 println!("{:p}", &s); // 0x16efee738 10 println!("{:p}", &s2); // 0x16efee740 11 12 // Values directly stored in `s` and `s2` 13 println!("{:p}", s); // 0x127e05f70 14 println!("{:p}", s2); // 0x16efee738 15 16 // Actual values stored on the heap 17 println!("{}", s); // 1 18 println!("{}", s2); // 1 19}</code></pre> The value immediately stored in s2</code> is just the address of the variable s</code> on the stack. In Rust's terms, s2</code> is an immutable reference to s</code>. What if we want to be able to mutate the inner value of the Box</code>? All variables in Rust are immutable unless explicitly changed to be mutable using the mut</code> keyword. There are also types that provide interior mutability (Cell<T></code>, RefCell<T></code>, Mutex<T></code>, and RwLock<T></code>), but they are a topic for another time! Order matters</a> </h3> Let's try that: 1// #8 2// main.rs 3 4fn main() { 5 let mut s = Box::new(1_i32); 6 *s = 2; 7 let s2 = &s; 8 9 //...rest of the code... 10 // The only change in the results is that the final set of `println!()` 11 // macros will print 2 instead of 1, which is no surprise! 12 // Addresses might also change which is expected but their causal 13 // relationship stays the same. 14}</code></pre> The code snippet number #8</code> compiles fine but the next one (#9</code>) doesn't: 1// #9 2// main.rs 3 4fn main() { 5 let mut s = Box::new(1_i32); 6 let s2 = &s; 7 *s = 2; 8 9 // Addresses of `s` and `s2` on the Stack 10 println!("{:p}", &s); 11 println!("{:p}", &s2); 12}</code></pre> Compilation fails with this error: | 6 | let s2 = &s; | -- `*s` is borrowed here 7 | *s = 2; | ^^^^^^ `*s` is assigned to here but it was already borrowed ... 11 | println!("{:p}", &s2); | --- borrow later used here</code></pre> Remembering the first rule of borrowing At any given time, you can have either one mutable reference or any number of immutable references to a value. </blockquote> In the code snippet number #8</code>, the value is borrowed after the mutation is done. So practically, the borrower will have a consistent view of the underlying memory. However, in snippet number #9</code>, the memory is mutated while there is a reference to it out there, which could potentially cause data races. Ok, nice but we're getting a little bit carried away! I will stop here to go back to the actual reason I thought this could be an interesting topic to discuss; To see if we could rewrite the exact C code in Rust without all that fancy borrowing stuff and by now, you are hopefully convinced it's not possible based on what we saw and experimented with. Unsafe</a> </h3> So far, we have been writing code in Safe Rust in which we have our compiler friend and its borrow checker as our supervisor. But there are certain situations such as interfacing with low-level system APIs (e.g., writing a device driver or calling foreign functions</a>) where we can't do much with the strict rules enforced by the borrow checker. That's where we need to enter the Unsafe Rust</a>. Here, the word unsafe doesn't really mean unsafe. So whenever we write an unsafe {}</code> block, we are asking the compiler to trust us, and that we have made sure this code is safe to run. Let's see how does that look like: 1// #10 2// main.rs 3 4fn main() { 5 let s = Box::new(1_i32); 6 let s2 = unsafe { std::ptr::read(&s) }; 7 8 // Addresses of `s` and `s2` on the Stack 9 println!("{:p}", &s); 10 println!("{:p}", &s2); 11 12 // Values directly stored in `s` and `s2` 13 println!("{:p}", s); 14 println!("{:p}", s2); 15 16 // Actual values stored on the heap 17 println!("{}", s); 18 println!("{}", s2); 19}</code></pre> If we simply write let s2 = unsafe { s };</code> it would still fail with the same error as let s2 = s;</code>. That's because s</code> still has type Box<i32></code>, which does not implement the Copy</code> trait! What we want to do is to copy the memory address stored in s</code> into s2</code> without invalidating s</code> itself (i.e., without causing a move to happen). Specifically, want to create a bitwise copy of the value stores in s</code> and save it in s2</code> in order to mimic what C did (int *s2 = s;</code>), right? Luckily, the Rust standard library provides a function that exactly does that. std::ptr::read()</code> which has this signature: pub const unsafe fn read(src: *const T) → T</code></pre> It reads the value from src</code> without moving it. This leaves the memory in src</code> unchanged. Running the program prints this output to the console: Finished dev [unoptimized + debuginfo] target(s) in 0.00s Running `target/debug/blog` 0x16d7566e8 0x16d7566f0 0x147605f70 0x147605f70 1 1 blog(51595,0x1d6f31000) malloc: Double free of object 0x147605f70 blog(51595,0x1d6f31000) malloc: *** set a breakpoint in malloc_error_break to debug [1] 51595 abort cargo run</code></pre> It executes and prints all addresses and values correctly but at the end, the program panics with this error message: malloc: Double free of object 0x147605f70</code></pre>Aha Moment</a> </h3> Sounds familiar? That's the mighty double-free issue we have been talking about which could easily happen in C but Rust is trying to solve, with its model of memory management. Why did a double-free happen? Remembering the last rule of ownership When the owner goes out of scope, the value will be dropped. </blockquote> What did we do? We cheated and stored two references of the same memory location (0x147605f70</code>) in two different variables.</li> We prevented Rust from moving the ownership to s2</code> and invalidating s</code>.</li> </ul> As a result, when s</code> and s2</code> go out of scope at the end of the main function, they both think they are the sole owner of the memory they point to and both will try to free that memory! It was an Aha Moment when I realized all that Ownership, Borrowing, values being Copy, and move semantics are just means by which Rust enables memory safety without runtime overhead. That's all I have for you in this blog post. Hope you have experienced an Aha moment by reading this too!

Conclusion

Addresses
Values and UB
Memory Layout

Values and UB
Memory Layout

Memory Layout

Aha Moment

MJ Pooladkhay

my first patch to the linux kernel

virtualization: theory to silicon

programming is modeling - an experience report

it’s all about memory