{"id":36134,"date":"2022-08-09T07:33:50","date_gmt":"2022-08-09T06:33:50","guid":{"rendered":"https:\/\/www.n-able.com\/?p=36134"},"modified":"2022-09-02T13:27:39","modified_gmt":"2022-09-02T12:27:39","slug":"what-happens-when-restart-mac","status":"publish","type":"post","link":"https:\/\/www.n-able.com\/it\/blog\/what-happens-when-restart-mac","title":{"rendered":"What actually happens when you restart your Mac?"},"content":{"rendered":"

It\u2019s a tale as old as time. Person meets computer. Computer starts acting odd. Person reboots computer.<\/span><\/p>\n

The act of restarting anything electronic seems to have an almost mystical ability to fix it when it\u2019s stopped working correctly. Internet connection is flaky? Restart the router. DVD player (remember those?) not syncing to the TV? Unplug the cables and try again. Toddler being cranky? Go take a nap.<\/span><\/p>\n

But, why?\u00a0<\/span><\/span><\/p>\n

If a device is entirely passive, it\u2019s instantly performing its task the moment it turns on\u2014like a lamp or a vacuum cleaner. The electrons go one way or another determined by physics alone. It could be years before such a device stops working, usually because a component fails. As long as the positive power rail has the right voltage and the other side is properly grounded, nothing short of physical failure will deter those electrons from their appointed rounds.<\/span><\/p>\n

So why does restarting even fairly simple electronic devices often fix a problem? Most instances can be explained by the physics of integrated circuits and chips, especially as they\u2019ve gotten smaller; though I\u2019m not an electrical engineer, so I can\u2019t speak to the specifics. A vague, hand-wavy explanation involves how the tiny components on a circuit board malfunction as things like static charge, heat, and capacitance build up. Removing the power resets the components to their baseline momentarily, and they usually stay within spec when powered back up<\/span>\u2014<\/span>at least for a while.<\/span>\u00a0<\/span><\/p>\n

For anything more complicated than a digital watch though, there are other factors at work. Once you\u2019re dealing with a Mac or other device that stores information in memory, or loads and runs programs to perform its function, it will need to be restarted more frequently.<\/span><\/p>\n

Er, excuse me<\/span>\u2014<\/span>who am I? Why am I here? What\u2019s my purpose in life?<\/span><\/h2>\n

There are two types of computer memory. (There are actually several more than that, but in the most general terms, two will suffice.) First: Memory chips that retain the information written to them, even when the power is off. These are what the flash storage in your phone or the SSD in your laptop are built from. This is what stores the programs and data that get loaded into the second type of memory when the computer starts up.<\/span><\/p>\n

That second type of memory only retains data as long as it has power. This is the RAM in your computer that\u2019s instantly erased when you pull the plug.<\/span><\/p>\n

I think you can see where I\u2019m going here.<\/span><\/p>\n

Modern memory and storage hardware is extremely densely packed and wickedly fast. To continue working at the extreme limits of size and speed, it\u2019s built with redundant error correcting algorithms to weed out the wrong bit flipping from a one to a zero. Memory corruption resulting from the occasional stray cosmic ray (yes, an actual thing that happens) doesn\u2019t even phase it. Actual hardware failure is rare, and isn\u2019t the kind of thing you can remedy just by restarting.\u00a0<\/span><\/span><\/p>\n

Most of the time, the problem isn\u2019t the hardware<\/span>\u2014<\/span>it\u2019s the software.<\/span><\/p>\n

It\u2019s people! It\u2019s made of people!<\/span><\/h2>\n

Well, made by<\/i> people.<\/span><\/p>\n

Because software is written by imperfect humans, any reasonably complicated piece of code contains bugs. They\u2019re (usually) not malicious, and if they were major problems, the development process should catch and weed them out before the product reaches customers. But tiny, sneaky ones remain\u2014the kinds of glitches that slowly build up over time and eventually overflow a number that has a limit of 65,535 over to 65,536. If you know a little about binary and powers of two, you\u2019ll recognize how that might be mistakenly read as a zero. That makes a tiny subtask that\u2019s part of a larger program hang-up for a little longer than expected, and everything you do on the machine takes an extra half second longer, and eventually you start to see the dreaded rainbow pinwheel and it\u2019s time to restart your Mac.<\/span><\/p>\n

This is where the fun begins<\/span><\/h2>\n

If all goes well, your command to shut down the Mac will result in the operating system instructing all the various processes to stop what they\u2019re doing and perform housekeeping\u2014finish any unfinished tasks, save and close any open files, and record their actions to their respective logs, etc. This continues down the process hierarchy until the tasks that manage all the other tasks are done managing themselves and then quietly pop out of existence. The operating system, alone in the void, sets a hardware register and the power management circuit pulls the metaphorical plug.<\/span>\u00a0<\/span><\/p>\n

Before I continue to the interesting bit, here\u2019s a short summary of proper shutdown procedure:<\/span><\/p>\n

I\u2019ve often seen long-time Mac users, when asked to shut down their computer, reach for the power button and hold it down until the screen turns black. That is definitely one way to power off your MacBook, but not ideal. This \u201cforced\u201d or \u201chard\u201d shutdown is best reserved for when the machine is completely unresponsive, and not just any time you need to turn it off. The aforementioned housekeeping tasks aren\u2019t performed, open files and unsaved changes are unceremoniously yanked out from file system, and the next time you start up, you\u2019ll get a nasty warning not to do that again. Be kind to your Mac and shut it down from the Apple Menu instead.<\/span><\/p>\n

Now, back to the program already in progress.<\/span><\/p>\n

I became curious about this topic as I was reading about the changes in security affecting the boot process as a result of Apple\u2019s move from Intel processors to their own ARM-based platform. Macs built around Apple Silicon, the collective name for the M1 and now M2 family of chips, follow a new boot process more akin to how iPhones and iPads start up. The rest of this post will delve into how these new Macs behave at power-on. If you\u2019re interested in the process of previous generations of Intel Macs, have a look at Apple\u2019s documentation here: https:\/\/support.apple.com\/guide\/security\/boot-process-sec5d0fab7c6\/web<\/span><\/a><\/span><\/p>\n

It’s Life, Jim<\/span><\/h2>\n

As the first trickle of power flows into the logic board, the system\u2019s memory is a blank slate. The RAM has been cleared by lack of current, and the only source of instructions for the processor reside in the non-volatile parts of memory. The CPU is wired to look first to a chunk of this read-only memory, the Boot ROM. Burned into the Boot ROM, and unchangeable by a user, hacker, or even Apple once it\u2019s been written, are instructions that read the memory containing the next stage of the boot process, and check that it is valid and unmodified.<\/span>\u00a0<\/span><\/p>\n

The processor, satisfied that the firmware code in this Low-Level Bootloader (LLB) is secure, then uses the LLB instructions to do the same verification for the firmware code stored in the various components that control access to storage, displays, networking, and so on. These controllers are occasionally flashed with updated firmware, which is signed by Apple in a way the LLB can verify as authentic.<\/span><\/p>\n

That done, the LLB code accesses and verifies the security configuration set by the user to determine how to proceed, and how restrictive to be when verifying the next stage, which will ultimately load the operating system. No, we\u2019re not quite there yet. Remember, this is all about the journey, not the destination.<\/span><\/p>\n

iBoot, which is the next evolution of the T2\/Intel Mac\u2019s BridgeOS or iBridge, is a shim between the firmware LLB and the macOS software kernel. This second stage is decrypted and loaded from its location on the boot drive, whereas everything up to this point has been stored in either ROM or flash storage on the logic board.\u00a0<\/span><\/span><\/p>\n

iBoot takes over and starts to fill up the system RAM with kernel components indicated by the configuration handed off to it by the LLB. When it\u2019s time to load the macOS kernel from the boot volume, it first has to run an integrity check on the volume, to be sure the file system the kernel resides in hasn\u2019t been tampered with. Its work done, iBoot cleans up behind itself and marks the regions of memory now occupied by the kernel as sacrosanct.<\/span><\/p>\n

macOS is finally resident in memory and continues to load the various extensions and components that transform a kernel into an operating system. This is when the user data volume is mounted, the hardware for which the firmware was verified earlier finally comes online, and the user is asked to sign in to decrypt their FileVault-secured data.<\/span><\/p>\n

I hope you remember your password.<\/span><\/p>\n

Some further reading:\u00a0<\/span><\/span><\/p>\n