3 ms·

> I'm not actually sure how system updates from the "regular use" side work with SIP enabled. They could have a special exception in the SIP infrastructure, but

> I'm not actually sure how system updates from the "regular use" side work with SIP enabled. They could have a special exception in the SIP infrastructure, but I doubt it. Apple Signed (with Apple's special key) Installers are allowed to modify system paths, including the current running system to install updaets.

derefr 11y ago
Interesting. I'm guessing that only gets used by minor "feature" updates (to e.g. Webkit, or iTunes), and not the full "OSX Update 10.11.x" releases. My suspicion is for anecdotal reasons: I recently Internet-restored my MBP. This pushed it back down to OSX 10.11.0, so it had quite a few OS point-updates to go install. But before I let it do any of those, I enabled FileVault2 and let it finish encrypting. I then had the "pleasure" of watching this sequence of events repeat itself several times, a sequence of events which had never occurred before El Capitan: 1. The OS asks to restart to install an update. 2. The OS reboots and sits at the (UEFI?) drive-unlock pretend-login screen until I enter my password. 3. The OS boots into something that looks like my "regular use" OS—the Menu Bar appears, the cursor appears and starts working, and my regular wallpaper is rendered—but the Finder doesn't start, nor do any of my account's Startup Items or LaunchAgents (not sure about global LaunchDaemons.) 4. The screen (still with HID cursor control enabled!) gets covered in a fullscreen window (not a fullscreened app taking up a Space; wrong transition effect) that has the appearance of a big black screen with an Apple logo and a progress bar. You know, like the boot screen, or iOS's update mode, or a Mac's UEFI firmware update mode. But it's definitely just an app, running within whatever instance of OSX this is. 5. Having completed the update, the computer reboots again, I enter my drive-unlock password again, and I'm back into my regular-use session. --- Previous to El Capitan, OSX Update packages would trigger a much simpler process, equivalent to the process Windows currently goes through: 1. Ask the user to "reboot"; 2. instead of rebooting, stop all userland processes and enter a single-user/maintenance runlevel; 3. run some special privileged (kext?) code that installs/unpacks/shoves the update and directly manipulates the framebuffer to render a progress bar; 4. actually reboot. --- It wouldn't make sense to change from the old process to the current one if it was just for the sake of putting the system into an SIP-disabled mode. Like you said, Apple-signed installers can flout SIP restrictions. It only makes sense to add the extra reboot to the process if you're rebooting into the recovery OS, because having the recovery OS do the work is itself the goal, rather than just an idea born out of necessity. If you're wondering about the "still has my wallpaper" part, though: it's not unprecedented for the recovery OS to be "fed" data from the regular-use OS, so that there's a continuity of control when you reboot into the recovery OS. For example, the recovery OS will receive a copy of any wi-fi AP keys you entered into the System keychain in the regular-use OS, so that you can re-install OSX even if you don't remember your wi-fi password. (I say "will receive a copy" instead of "accesses" because it gets these even if the regular-use OS is sitting in the FileVault2 "locked" state from the recovery OS's perspective—or has already been blown away entirely—where it couldn't possibly just mount the volume to read your System keychain. It seems to be more that the regular-use OS will push a copy of these thing over into the recovery OS when you update them.)

derefr 11y ago

Interesting. I'm guessing that only gets used by minor "feature" updates (to e.g. Webkit, or iTunes), and not the full "OSX Update 10.11.x" releases. My suspicion is for anecdotal reasons: I recently Internet-restored my MBP. This pushed it back down to OSX 10.11.0, so it had quite a few OS point-updates to go install. But before I let it do any of those, I enabled FileVault2 and let it finish encrypting. I then had the "pleasure" of watching this sequence of events repeat itself several times, a sequence of events which had never occurred before El Capitan: 1. The OS asks to restart to install an update. 2. The OS reboots and sits at the (UEFI?) drive-unlock pretend-login screen until I enter my password. 3. The OS boots into something that looks like my "regular use" OS—the Menu Bar appears, the cursor appears and starts working, and my regular wallpaper is rendered—but the Finder doesn't start, nor do any of my account's Startup Items or LaunchAgents (not sure about global LaunchDaemons.) 4. The screen (still with HID cursor control enabled!) gets covered in a fullscreen window (not a fullscreened app taking up a Space; wrong transition effect) that has the appearance of a big black screen with an Apple logo and a progress bar. You know, like the boot screen, or iOS's update mode, or a Mac's UEFI firmware update mode. But it's definitely just an app, running within whatever instance of OSX this is. 5. Having completed the update, the computer reboots again, I enter my drive-unlock password again, and I'm back into my regular-use session. --- Previous to El Capitan, OSX Update packages would trigger a much simpler process, equivalent to the process Windows currently goes through: 1. Ask the user to "reboot"; 2. instead of rebooting, stop all userland processes and enter a single-user/maintenance runlevel; 3. run some special privileged (kext?) code that installs/unpacks/shoves the update and directly manipulates the framebuffer to render a progress bar; 4. actually reboot. --- It wouldn't make sense to change from the old process to the current one if it was just for the sake of putting the system into an SIP-disabled mode. Like you said, Apple-signed installers can flout SIP restrictions. It only makes sense to add the extra reboot to the process if you're rebooting into the recovery OS, because having the recovery OS do the work is itself the goal, rather than just an idea born out of necessity. If you're wondering about the "still has my wallpaper" part, though: it's not unprecedented for the recovery OS to be "fed" data from the regular-use OS, so that there's a continuity of control when you reboot into the recovery OS. For example, the recovery OS will receive a copy of any wi-fi AP keys you entered into the System keychain in the regular-use OS, so that you can re-install OSX even if you don't remember your wi-fi password. (I say "will receive a copy" instead of "accesses" because it gets these even if the regular-use OS is sitting in the FileVault2 "locked" state from the recovery OS's perspective—or has already been blown away entirely—where it couldn't possibly just mount the volume to read your System keychain. It seems to be more that the regular-use OS will push a copy of these thing over into the recovery OS when you update them.)