Why macOS anti-malware scans can behave oddly
eclecticlight.co
eclecticlight.co
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
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.
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...