51–60 of 71 posts
Earlier quoted context omitted.
If it doesn't end up with the relevant people, that's Apple's problem.
It does eventually. If you want a prompt response you should contact product security.
My naïve guess is that this is probably some sort of lock contention thing.
Earlier quoted context omitted.
Do you know what the underlying problematic instruction sequence is? Or the precise location where it halts?
I have no idea how I could find that, given that the system freezes completely. Maybe tracing the CPU instructions using LLDB might be possible, but the bug is most likely in the kernel code so this would not help much.
Earlier quoted context omitted.
It does eventually. If you want a prompt response you should contact product security.
Shouldn't Apple be the ones who really want to respond promptly? Why should we work around bugs in Apple's issue reporting system?
It's very easy to freeze a system as a non-root user; cause too many interrupts, consume too many resources, etc. Many kinds of infinite loop will lock a system hard. Hell, you can crash systems with too many packets . And it's very easy to cause ps to hang. Many different kernel syscalls hang / are blocking. Mostly you see this with kernel features dependent on a resource that doesn't resolve itself, like a stuck di…
Earlier quoted context omitted.
It does eventually. If you want a prompt response you should contact product security.
Shouldn't Apple be the ones who really want to respond promptly? Why should we work around bugs in Apple's issue reporting system?
Earlier quoted context omitted.
Shouldn't Apple be the ones who really want to respond promptly? Why should we work around bugs in Apple's issue reporting system?
I don’t really see the problem with getting faster responses by contacting Apple’s security team directly for potential vulnerabilities when compared to the general-purpose bug tracker.
Coincidentally, I also stumbled upon a way to make the kernel of Apple Silicon Macs panic and restart while developing the https://lowtechguys.com website. I distilled the problem in a repo so it can be reproduced with a single command: https://github.com/alin23/m1-panic I found it while on Monterey and reported it 2 times through Feedback Assistant, but it still happens on Ventura. NOTE: Don't try it without saving…
Might have been better to report it to the security people. This sort of thing can be exploitable.
I have no idea of they work on the arm Macs, but I will have the ability to check in a couple of days. Probably nothing exploitable, but still a hard crash.
It's very easy to freeze a system as a non-root user; cause too many interrupts, consume too many resources, etc. Many kinds of infinite loop will lock a system hard. Hell, you can crash systems with too many packets . And it's very easy to cause ps to hang. Many different kernel syscalls hang / are blocking. Mostly you see this with kernel features dependent on a resource that doesn't resolve itself, like a stuck di…
While what you say is true, these are nonetheless kernel bugs. The kernel should never let any user process consume so many resources as to cause a system freeze. The kernel must not only be able to preempt any user process at any time, stopping it to consume all CPU time, but it must also prevent any user process to completely fill a SSD or HDD, because that can prevent many programs from starting.
A phone is different since it always has to be able to make phone calls.