blob: 61bbec438d6a3a2f45c26c8cdc6490214233f5c8 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I need to figure out whether this qemu-img crash on an M1 Mac is a user-mode or system-mode issue. Let me start by going through the information provided.
The user mentioned that when they run `qemu-img create -f qcow2 disk.qcow2 10G`, it crashes with the process being killed. The environment includes an Apple M1 CPU, macOS Big Sur 11.2.2, and qemu version 5.2.0 installed via Homebrew.
Looking at the kernel logs, there are mentions of code signing issues. Specifically, the error is about rejecting an invalid page in a dylib file (`libssh.4.8.6.dylib`). The crash log shows that the process crashed with an exception related to accessing memory that's not properly signed or authorized.
The stack trace points to `dyld` (the dynamic linker) and functions involved in loading libraries, which suggests that there's an issue during the initialization phase of the program. This typically happens when the code isn't properly signed or is modified after signing, causing macOS's security features to block it.
Since the problem arises from dylib loading and code signing issues, this seems like a user-mode problem because it's related to how the application (qemu-img) interacts with its own libraries. It doesn't involve kernel operations, device drivers, or hardware-level access, which would be system-mode issues. Instead, it's more about the application's executables and their dependencies not meeting macOS's security requirements.
So, I think this is a user-mode issue because it pertains to how the application and its libraries are being loaded into memory by the dynamic linker without proper authorization.
</think>
user
|