←back to thread

MacOS Catalina: Slow by Design?

(sigpipe.macromates.com)
2031 points jrk | 5 comments | | HN request time: 0.204s | source
Show context
brendangregg ◴[] No.23277837[source]
Adding network calls to syscalls like exec() is utterly insane. This road can lead to bricked laptops where you can't run anything to fix it (imagine an unexpected network error that the code doesn't handle properly). And crackers will just use ways to overwrite running instruction text to avoid the exec().

The comments on the article are annoying: it good that there's a mini way to reproduce, but please, use some further debugging like tcpdump (it still exists on osx, right?). Last time I summarized osx debugging was https://www.slideshare.net/brendangregg/analyzing-os-x-syste...

I'd also stress test it: generate scripts in a loop that include random numbers and execute them.

replies(5): >>23278280 #>>23279465 #>>23279751 #>>23279958 #>>23303509 #
1. ridiculous_fish ◴[] No.23279751[source]
The kernel sources are available.

https://opensource.apple.com/source/xnu/xnu-6153.81.5/

replies(2): >>23279935 #>>23291734 #
2. saagarjha ◴[] No.23279935[source]
…with everything to do with the sandbox left out.
replies(1): >>23280079 #
3. ridiculous_fish ◴[] No.23280079[source]
Fair point. These tarballs may be, err, editorialized.

If exec is blocking in the kernel on IPC to some daemon, that should be observable (e.g. Instruments with kernel traces enabled).

replies(1): >>23280157 #
4. saagarjha ◴[] No.23280157{3}[source]
Yeah, I'm sure a good spindump would be able to find what the code is blocked on. Sadly I run with SIP disabled so I can attach to things, so I probably cannot reproduce the issue…
5. m463 ◴[] No.23291734[source]
Most of the important parts are left out.

at this point opensource and apple are sort of on life support.