Why macOS anti-malware scans can behave oddly • Hacker News Board

Re: Why macOS anti-malware scans can behave oddly

#21

Post by jonhohle » Sun, Aug 13, 2023, 7:03 PM UTC

arghwhat wrote: post #14

mschuster91 wrote: post #11

Earlier quoted context omitted.

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…

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 perspecti…

In a sleep state there is no kernel running, it’s a hardware feature that stops CPU execution and possibly more depending on the sleep state.

Re: Why macOS anti-malware scans can behave oddly

#22

Post by MBCook » Sun, Aug 13, 2023, 7:12 PM UTC

Kognito wrote: post #18

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 bee…

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.

Re: Why macOS anti-malware scans can behave oddly

#23

Post by rcxdude » Sun, Aug 13, 2023, 7:36 PM UTC

jonhohle wrote: post #21

arghwhat wrote: post #14

Earlier quoted context omitted.

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 perspecti…

In a sleep state there is no kernel running, it’s a hardware feature that stops CPU execution and possibly more depending on the sleep state.

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.

Re: Why macOS anti-malware scans can behave oddly

#24

Post by kibwen » Sun, Aug 13, 2023, 7:43 PM UTC

nickpeterson wrote: post #20

tinus_hn wrote: post #17

Earlier quoted context omitted.

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.

People are used to the old days when a computer would come on in a bag and overheat itself.

The old days of last year, when my MacBook did exactly this. "Smart sleep" is a shambles, give me a real hibernate option please.

Re: Why macOS anti-malware scans can behave oddly

#25

Post by kergonath » Sun, Aug 13, 2023, 8:05 PM UTC

mschuster91 wrote: post #11

MaxikCZ wrote: post #8

Earlier quoted context omitted.

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…

> 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).

Re: Why macOS anti-malware scans can behave oddly

#26

Post by jwells89 » Sun, Aug 13, 2023, 8:14 PM UTC

kibwen wrote: post #24

nickpeterson wrote: post #20

Earlier quoted context omitted.

People are used to the old days when a computer would come on in a bag and overheat itself.

The old days of last year, when my MacBook did exactly this. "Smart sleep" is a shambles, give me a real hibernate option please.

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.

Re: Why macOS anti-malware scans can behave oddly

#27

Post by FirmwareBurner » Sun, Aug 13, 2023, 8:15 PM UTC

Kognito wrote: post #18

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 bee…

"Malware on Macs does not exist" - 'waving Jedi hand'

Re: Why macOS anti-malware scans can behave oddly

#28

Post by TillE » Sun, Aug 13, 2023, 8:16 PM UTC

Kognito wrote: post #18

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 bee…

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.

Re: Why macOS anti-malware scans can behave oddly

#29

Post by andrekandre » Sun, Aug 13, 2023, 10:06 PM UTC

hunters_laptop wrote: post #4

"Instead it records those events in the log, and in Ventura and later makes them available to third-party software through Endpoint Security events." Sounds like what malware did for decades

thats interesting, i'm guessing it means slowly third-party scanning will become more and more rare?

currently my battery-life really suffers with third-party scanning burning through my m1 cores after a build...

Re: Why macOS anti-malware scans can behave oddly

#30

Post by arghwhat » Sun, Aug 13, 2023, 10:18 PM UTC

rcxdude wrote: post #23

jonhohle wrote: post #21

Earlier quoted context omitted.

In a sleep state there is no kernel running, it’s a hardware feature that stops CPU execution and possibly more depending on the sleep state.

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.