Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why macOS anti-malware scans can behave oddly

eclecticlight.co

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Why macOS anti-malware scans can behave oddly

#41

Post by callalex »

Terretta wrote: post #36
JadeNB wrote: post #35

Earlier quoted context omitted.

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

> I feel betraying their BSD roots along the way 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?

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.

Re: Why macOS anti-malware scans can behave oddly

#42

Post by roydivision »

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…

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.

Re: Why macOS anti-malware scans can behave oddly

#43

Post by TazeTSchnitzel »

roydivision wrote: post #42
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…

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.

https://youtube.com/watch?v=V0feR5grSa4

Re: Why macOS anti-malware scans can behave oddly

#44

Post by roydivision »

TazeTSchnitzel wrote: post #43
roydivision wrote: post #42

Earlier quoted context omitted.

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.

https://youtube.com/watch?v=V0feR5grSa4

Good call, I stand corrected.

Re: Why macOS anti-malware scans can behave oddly

#45

Post by arghwhat »

astrange wrote: post #40
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…

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

Re: Why macOS anti-malware scans can behave oddly

#46

Post by MaxikCZ »

arghwhat wrote: post #33
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.

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, reinitia…

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

Post reply on HN