Concurrency and Asynchronous Programming: a Detailed Overview 16 and instead of simply copying the memory address itself to {0}, it will fetch what's at that memory location and move it over. Anyway, we're just writing instructions to the CPU here. No standard library, no syscall; just raw instructions. There is no way the OS is involved in that dereference function, right? If you run this program, you get what you' d expect: 100 Now, if you keep the dereference function but replace the main function with a function that creates a pointer to the 99999999999999 address, which we know is invalid, we get this function: fn main() { let t_ptr = 99999999999999 as *const usize; let x = dereference(t_ptr); println!("{}", x); } Now, if we run that we get the following results. This is the result on Linux: Segmentation fault (core dumped) This is the result on Windows: error: process didn't exit successfully: `target\debug\ac-assembly-dereference. exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION) We get a segmentation fault. Not surprising, really, but as you also might notice, the error we get is different on different platforms. Surely, the OS is involved somehow. Let's take a look at what's really happening here. Down the rabbit hole It turns out that there is a great deal of cooperation between the OS and the CPU, but maybe not in the way you would naively think. Many modern CPUs provide some basic infrastructure that operating systems use. This infrastructure gives us the security and stability we expect. Actually, most advanced CPUs provide a lot more options than operating systems such as Linux, BSD, and Windows actually use. There are two in particular that I want to address here: How the CPU prevents us from accessing memory we're not supposed to access How the CPU handles asynchronous events such as I/O