-
Notifications
You must be signed in to change notification settings - Fork 847
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
search command will crash qemu process #1931
Comments
Any stack trace? Any minimal PoC? :( |
I am going to make a detail readme.md and see you later. |
the full detail is : #!/bin/bash 02-start gdb 03-search 04-quit |
i have to say that when searching , we have to wait for a long time ,and i tried to attach qemu, finally i droped it . |
This is completely speculation, so please forgive me if I'm wrong. I know a problem with searching the entire memory with qemu-system. |
another thing i wanna to add is , configure like this:
then debugger can see alot memory |
I haven’t yet dived into the issue but I want to put a note here that we
offload searching to GDB which may or may not be optimal. I am going to see
if this can be optimized at GDB side of things (although if so, it will
take a bit time for them to pull it and release it).
…On Tue, 21 Nov 2023 at 05:01, boy1337 ***@***.***> wrote:
another thing i wanna to add is , configure like this:
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
then debugger can see alot memory
—
Reply to this email directly, view it on GitHub
<#1931 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACMLWCTUADBL7NA6O52Z6J3YFQRQTAVCNFSM6AAAAAA67EPZZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRQGIYDCOBSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
really thanks for your work!! |
昨天尝试,问题依旧存在 |
I discovered an area that may be one of the causes.
However, there are cases where it does not crash even when accessed.
I don't know the cause of this. |
@bata24 Thanks for more info! But what exactly do u debug that causes this? I guess this may differ based on the target? E.g. remote gdbserver vs QEMU user vs QEMU kernel vs real device debug bridge? |
Suppose the GIC area is the cause. We need to consider GIC when debugging kernels and bear metal firmware. In other words, qemu-system, OpenOCD, KGDB stub, VMware stub, etc. are at least targets to be considered. Conversely, I don't think qemu-user and gdbserver are target. By the way, the area where GIC exists seems to be different for each environment, so it seems to be represented by a device tree. Therefore, to identify the GIC area (for the purpose of avoiding access to this area), it is limited when we can read the information of device tree from the GDB side. The case of qemu-system can be identified with the |
amazing that u can test the root cause!! |
afterqemu-system-aarch64 start android kernel, and when use gdb with pwndbg, command search will crash afterqemu-system-aarch64
The text was updated successfully, but these errors were encountered: