I would have preferred if the scan was also performed when in sleep (I mean by wake up the system silently) but know that macOS keep itself a bit more secure is a good thing.
> I would have preferred if the scan was also performed when in sleep (I mean by wake up the system silently)
Bad, bad idea. It's really bad if the system decides to wake up for any reason on its own - my AirPods used to be really bad for a while, despite setting them to "connect with last device" they'd connect to my work MacBook spontaneously instead of my tablet, wake up the laptop, something would prevent it from going back to sleep and since it was stored in my bag it would heat up until the overtemperature safety shutoff and drain the battery in the process.
In this case its the execution that was bad. If the MacOS would wake silently knowing the purpose is to scan and do nothing else, all the useless stuff for it could (and should) be kept off. Then such thing could not happen.
No OS supports just waking up "specific" processes only after a resume from standby. IIRC Apple does but in a fake way - they just wake up the T2 chip and its dedicated OS, which is a ton of work to get right (as state of hardware must be coordinated between macOS and bridgeOS), and only Apple can do this because (other than servers with iLO/equivalent) no x86 machine has a similarly capable coprocessor.
Edit: never mind, I must have gotten something wrong, T2 is not capable of that.
There is no technical limitation, the kernel is free to schedule whatever it wants. The appearance that everything never stopped running is an illusion the kernel does active work to implement - heck, in the case of hibernation it is even after a normal cold boot like any other.
Resuming to only run specific processes - or resuming to run an entirely different, temporary userspace - is trivial from a kernel perspective.
The kernel is still heavily involved in the process of going to sleep: it needs to coordinate the process, which includes freezing userspace execution. So it can quite easily unfreeze only a portion of the userspace. The main trick is making sure that the unfrozen bits aren't depending on the frozen bits, which is probably hard in general thanks to locks.
Userspace locks are generally per process (or process group), so it shouldn't matter. There can be IPC dependencies and file locks and what not, but none of that matters if you only run something you control and therefore can ensure have no odd dependencies.
Sleep states are not a switch you just flick - that be equivalent to you pulling the power cord.
Even in the highest, most power hungry sleep states the kernel has to pause everything first, power down all the other hardware (otherwise you'd still have you WiFi card and GPU running full tilt), configure what will interrupt the CPU sleep and finally start it. On the other end it has to set everything back up, reinitialize all the other hardware to be in the same state as before, and finally start running user space again - pretending nothing happened even though the foundation was removed and rebuilt.
The only real difference to full hibernation - where the machine is powered off entirely and the kernel restores system state from a snapshot it wrote to disk - is that the RAM state sticks around and that the CPU executes the kernel again on wake instead of dropping to the firmware boot sequence.
Without that boot sequence, hibernate would basically be indistinguishable from suspend - an Phoronix article some years back talked about how Intel tuned the kernel to get from cold boot to full interactive UI in 300ms for automotive usecases.
> boot to full interactive UI in 300ms for automotive usecases.
Amazing. In the meantime latest Skoda infotainments are starting up when they detect a key approaching the car to be at least somewhat ready by the time you start the car and drive. My friend states that for switching off a "simulate engine noise inside cabin" he need to let infotaintment "warm up" for another minute or two, before it becomes responsive enough to actually be able to turn that off.
> Resuming to only run specific processes - or resuming to run an entirely different, temporary userspace - is trivial from a kernel perspective.
The first is rather difficult from a system perspective, because if you suspend anything you'll get deadlocks if anything else calls it, or memory growth if anything else sends IPC to it that gets buffered.
You can throttle them instead, but actually suspending is hard.
> because if you suspend anything you'll get deadlocks if anything else calls it
Processes do not call other processes, and nothing in userspace can make a (non-buggy) kernel deadlock. Processes could be waiting on IPC or user-space coordination like file locks, but we don't care about the normal user-space - our special process would not take file locks or try to IPC with other processes, as it's designed for this use-case.
> or memory growth if anything else sends IPC to it that gets buffered.
When you send something on a pipe, the sending process stops executing and the receiving process becomes runnable and eventually scheduled to read the data. The sending side will not get scheduled again until the receiving side completed the read.
For anything buffered the same happens once the buffer fills. Nothing will grow unbounded, and behavior when other user-space applications do not run is perfectly well-defined and a constantly exercised.
After all, remember that processes only get to run occasionally if at the start of a scheduling epoch the kernel feels like it, they are preempted at random mid execution, they are delayed by other things (including realtime processes that can delay other things indefinitely, higher priorities, other niceness, CPU quotas, whatnot), and so on. The idea of continuous process execution is a very, very rough illusion.
What this would take is basically just something to make the scheduler disregard most processes that are technically runnable in this semi-suspend state, only picking kernel threads and specially marked processes.
> No OS supports just waking up "specific" processes only after a resume from standby.
PowerNap does something like this, actually, and had been doing it for years when the T2 was introduced (since Mountain Lion, IIRC, on bog standard Intel cores).
macOS already wake up itself lots of time but keeping the display and other services off, it’s called PowerNap. It downloads mails and updates, so the same for the malware protection would not be a bad idea.
In addition to this, this feature is optional, there is a clearly labeled switch in the settings to turn this on or off if for some reason people have strong feelings against it.
In my experience, Power Nap probably isn’t the problem, because turning off wake on LAN eliminates bag-waking entirely on macOS and greatly mitigates it under Windows.
Really, it’s rather strange that laptops have wake on LAN enabled by default. It makes some sense on desktops (though I disable it there too so my gaming PC doesn’t randomly rouse itself from hibernation at 3AM), but not at all on laptops.
I would note that there's definitely a reason that macOS hasn't attached anti-malware scanning (or similar things, e.g. Spotlight indexing) to DarkWake wakeups, though.
The other things DarkWake does are all IO-bound (network activity, disk activity) with a bounded workload size (the size of the update); while anti-malware scans would be CPU-bound (lots of hashing for signature checking) with an unbounded workload size (however much stuff you have on your HD.)
Doing IO-bound activity, just on some efficiency cores, in their base power state, for a minute or two, is fine; even if the laptop is in your bag, it won't heat up, any more than your phone heats up in your pocket. Doing "real work" in the same situation is not fine.
In this case, it's for enterprise MDM and MDR software agents that have device-level trust after the device has been enrolled (e.g., Apple Business Manager, Microsoft Intune, Kandji, Jamf).
I've always found it interesting that XProtect is completely invisible to the average user, whereas MS Defender is very much in your face (at least it was last time I used Windows). I suppose it's to quietly reinforce the narrative that Macs "don't get malware".
If they do, but you never know about it before its dealt with, to the average user it's as good as it never having happened. Unless of course, damage has been done/data stolen/etc - in which case I suppose the user never finds out?
I really wouldn't mind a UI for XProtect buried somewhere deep in the settings.
I would put it more towards Apple’s general philosophy of “the user shouldn’t have to care about that” than trying to uphold an image from a (extremely popular) 15 year old ad campaign.
That said I agree it’s great that it’s there and I like that it doesn’t bother if I don’t need to be involved.
> I would put it more towards Apple’s general philosophy of “the user shouldn’t have to care about that” than trying to uphold an image from a (extremely popular) 15 year old ad campaign.
Apple's general philosophy has always been "the user shouldn't have to care about that", but they've moved more and more recently to "the user shouldn't even be able to do anything about that" (I feel betraying their BSD roots along the way), and this seems to be an instance of that.
As a BSD 4.3, BSDi, FreeBSD, and now MacOS user, I'm not finding MacOS shell environment to be crippled in recent releases. If anything, even the ecosystem available to me through brew keeps getting broader as more and more tools add support.
What do you feel Apple has taken away from you at the CLI?
Not CLI related but here is a petty example of Apple taking something that worked for years and just dropping it. 1080i (interlaced) display support. My home theater tv supports 1080i but not 1080p, and I’ve been happily powering it with a Mac Mini running Kodi. A few years ago I “upgraded” macOS and lo and behold Apple just -decided- that I don’t need 1080i anymore and dropped support. No good reason, just “Fuck you, user. You don’t need this.”
Apple’s recent history is full of these “we know better and you don’t need this” decisions.
Two come to mind
1. System Integrity Protection breaking sudo (I understand why the trade off is worthwhile but it can be painful sometimes)
2. APFS pulling endless opaque shenanigans when it comes to what uses disk space and which tools report what usage, and where data lives. The permissions model clashes badly with shell usage, and blatantly disrespects sudo.
I think maybe this was changed quite recently, but for a long time Windows 10/11 would send you periodic notifications that Defender had done a scan and found no threats. Pointless and briefly alarming; I do not expect to get AV notifications unless there's a problem.
I'm glad there's a GUI though, which lets you do a deep scan on boot and other stuff.
I’m on 11 Insider Preview on my work machine and about once a week I get a notification that says something to the effect of Defender not finding anything after scanning five times.
In my experience the narrative that Macs don't get malware doesn't come from Apple themselves. Apple are not dumb, making public such a claim would be waving a giant red flag in front of potential malware writers. It would also be embarrassingly regurgitated if there ever was a serious threat.
45 comments
[ 3.0 ms ] story [ 97.3 ms ] threadBad, bad idea. It's really bad if the system decides to wake up for any reason on its own - my AirPods used to be really bad for a while, despite setting them to "connect with last device" they'd connect to my work MacBook spontaneously instead of my tablet, wake up the laptop, something would prevent it from going back to sleep and since it was stored in my bag it would heat up until the overtemperature safety shutoff and drain the battery in the process.
Edit: never mind, I must have gotten something wrong, T2 is not capable of that.
Resuming to only run specific processes - or resuming to run an entirely different, temporary userspace - is trivial from a kernel perspective.
Even in the highest, most power hungry sleep states the kernel has to pause everything first, power down all the other hardware (otherwise you'd still have you WiFi card and GPU running full tilt), configure what will interrupt the CPU sleep and finally start it. On the other end it has to set everything back up, reinitialize all the other hardware to be in the same state as before, and finally start running user space again - pretending nothing happened even though the foundation was removed and rebuilt.
The only real difference to full hibernation - where the machine is powered off entirely and the kernel restores system state from a snapshot it wrote to disk - is that the RAM state sticks around and that the CPU executes the kernel again on wake instead of dropping to the firmware boot sequence.
Without that boot sequence, hibernate would basically be indistinguishable from suspend - an Phoronix article some years back talked about how Intel tuned the kernel to get from cold boot to full interactive UI in 300ms for automotive usecases.
Amazing. In the meantime latest Skoda infotainments are starting up when they detect a key approaching the car to be at least somewhat ready by the time you start the car and drive. My friend states that for switching off a "simulate engine noise inside cabin" he need to let infotaintment "warm up" for another minute or two, before it becomes responsive enough to actually be able to turn that off.
The first is rather difficult from a system perspective, because if you suspend anything you'll get deadlocks if anything else calls it, or memory growth if anything else sends IPC to it that gets buffered.
You can throttle them instead, but actually suspending is hard.
Processes do not call other processes, and nothing in userspace can make a (non-buggy) kernel deadlock. Processes could be waiting on IPC or user-space coordination like file locks, but we don't care about the normal user-space - our special process would not take file locks or try to IPC with other processes, as it's designed for this use-case.
> or memory growth if anything else sends IPC to it that gets buffered.
When you send something on a pipe, the sending process stops executing and the receiving process becomes runnable and eventually scheduled to read the data. The sending side will not get scheduled again until the receiving side completed the read.
For anything buffered the same happens once the buffer fills. Nothing will grow unbounded, and behavior when other user-space applications do not run is perfectly well-defined and a constantly exercised.
After all, remember that processes only get to run occasionally if at the start of a scheduling epoch the kernel feels like it, they are preempted at random mid execution, they are delayed by other things (including realtime processes that can delay other things indefinitely, higher priorities, other niceness, CPU quotas, whatnot), and so on. The idea of continuous process execution is a very, very rough illusion.
What this would take is basically just something to make the scheduler disregard most processes that are technically runnable in this semi-suspend state, only picking kernel threads and specially marked processes.
PowerNap does something like this, actually, and had been doing it for years when the T2 was introduced (since Mountain Lion, IIRC, on bog standard Intel cores).
Really, it’s rather strange that laptops have wake on LAN enabled by default. It makes some sense on desktops (though I disable it there too so my gaming PC doesn’t randomly rouse itself from hibernation at 3AM), but not at all on laptops.
I would note that there's definitely a reason that macOS hasn't attached anti-malware scanning (or similar things, e.g. Spotlight indexing) to DarkWake wakeups, though.
The other things DarkWake does are all IO-bound (network activity, disk activity) with a bounded workload size (the size of the update); while anti-malware scans would be CPU-bound (lots of hashing for signature checking) with an unbounded workload size (however much stuff you have on your HD.)
Doing IO-bound activity, just on some efficiency cores, in their base power state, for a minute or two, is fine; even if the laptop is in your bag, it won't heat up, any more than your phone heats up in your pocket. Doing "real work" in the same situation is not fine.
Sounds like what malware did for decades
currently my battery-life really suffers with third-party scanning burning through my m1 cores after a build...
If they do, but you never know about it before its dealt with, to the average user it's as good as it never having happened. Unless of course, damage has been done/data stolen/etc - in which case I suppose the user never finds out?
I really wouldn't mind a UI for XProtect buried somewhere deep in the settings.
That said I agree it’s great that it’s there and I like that it doesn’t bother if I don’t need to be involved.
Apple's general philosophy has always been "the user shouldn't have to care about that", but they've moved more and more recently to "the user shouldn't even be able to do anything about that" (I feel betraying their BSD roots along the way), and this seems to be an instance of that.
As a BSD 4.3, BSDi, FreeBSD, and now MacOS user, I'm not finding MacOS shell environment to be crippled in recent releases. If anything, even the ecosystem available to me through brew keeps getting broader as more and more tools add support.
What do you feel Apple has taken away from you at the CLI?
Apple’s recent history is full of these “we know better and you don’t need this” decisions.
I'm glad there's a GUI though, which lets you do a deep scan on boot and other stuff.
I can't remember the last time I saw the Defender UI