从进程上下文中跟踪内核中的单步？
我想知道如果从内核（本例中为 Linux）在进程上下文（系统调用、页面错误等）中使用 PTRACE_SINGLESTEP 调用 ptrace_request 会发生什么。它会单步执行用户空间指令还是内核空间指令。我意识到 ptrace 只能单步执行用户指令，这就是为什么我对这会产生的行为感到好奇。
只是为了提供更多信息，我尝试从页面错误处理程序执行此操作（单步执行发生错误的指令，但更改 PTE 以便指令通过）。我想知道这是否可能，或者是否需要另一种方法来执行此操作，例如重新安排进程运行等......
出现这种情况是因为进程的task_struct（如果被抢占）仍然会指向内核空间处理程序 IIRC 那么使用 ptrace 单步执行会绕过这个并执行正确的用户空间指令还是根本不执行？
I was wondering what happens if from the kernel (Linux in this case) you call ptrace_request with PTRACE_SINGLESTEP in process context (system call, page fault, etc...). Will it single step the user space instruction or the kernel space instruction. I realize that ptrace can only single step user instructions which is why I'm curious as to the behavior that this would produce.
Just to provide a little more information, I am attempting to do so from a page fault handler (single step the instruction that faulted but change PTE so that the instruction goes through). I am wondering if this is even possible at all or if it would require another method to do so such as rescheduling the process to run, etc....
This comes up because the task_struct for the process (if preempted) will still point to the kernel space handler IIRC so would single stepping with ptrace bypass this and do the correct user space instruction or just not do it at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不完全理解你的意思，PTRACE_SINGLESTEP 总是在用户上下文中从内核调用：当你执行系统调用 ptrace(PTRACE_SINGLESTEP) 时，你最终将在内核上下文中执行该函数，该函数的行为将像往常一样使您正在跟踪的进程执行一条指令，无论您是否从页面错误处理程序调用它。当它像往常一样位于内核区域时，您将无法单步执行它。
我建议您查看 arch/x86/kernel/ptrace.c 以了解单个步骤的实际工作原理。单步指令实际上是由内核模拟的，IIRC对此没有硬件支持。
I don't fully understand what you mean by all this, PTRACE_SINGLESTEP is always called from kernel in user context: when you do your syscall ptrace(PTRACE_SINGLESTEP), you will end up in kernel context executing that function, which will behave as usually and make the process you are ptracing execute one instruction, no matter if you call it from the page fault handler. You won't be able to single step it while it is in kernel land as usual.
I recommend you take a look at arch/x86/kernel/ptrace.c to understand how the single step actually works. The single stepped instruction is actually emulated by the kernel, IIRC there is no hardware support for this.
要了解您问题的答案，您需要了解英特尔硬件。
首先我们从最简单的指令开始（因为SINGLE_STEP是让Intel CPU进入单步模式，执行完一个指令后返回到中断处理程序）：
movl (eax), ebx
遵循Intel的格式，这意味着取里面的值eax，将其视为内存指针，访问内存，获取4字节值并将其复制到ebx。
这一条汇编指令 - 在内核与用户上下文中执行时将具有不同的行为/含义。
如果在内核中，内核的页表将用于访问内存，并将数据复制到ebx。在用户进程中，将使用用户的页表（顺便由 MMU 硬件）从内存读取数据并复制到 ebx。 eax 中的值相同，但 CR3 寄存器中的值不同（意味着不同的进程上下文），将触发读取内存的不同部分。所以在内核中跟踪用户空间程序，真是可笑。因为你必须在执行用户指令之前和之后进行上下文切换（这涉及到整组寄存器的存储和恢复操作）——这意味着有效的4个操作。
正如你所看到的，我没有像你提到的那样引用任何内核函数 API。总体概念理解是第一位的。
To understand the answer to your question, you need to understand Intel hardware.
First we start with the simplest instruction (because SINGLE_STEP is to put the Intel CPU into single stepping mode, and returning back to the interrupt handler after executing one struction):
movl (eax), ebx
Following Intel's format, this means taking the values inside eax, treat it as a memory pointer, access the memory, get the 4 byte values and copy it to ebx.
This ONE assembly instruction - when executed in kernel vs user context will have DIFFERENT behavior/meaning.
If in kernel, the kernel's pagetable will be used to access the the memory, and copy the data to ebx. In a user process, the user's pagetable will be used (by MMU hardware by the way) to read the data from memory and copy to ebx. Identical values in eax, but with different values in CR3 register (meaning different process context), will trigger different parts of the memory to be read. So tracing userspace program in the kernel, is really ridiculous. Because u have to do a context switch (which involved the whole set of registers store and restoration operation), done before and after executing the user instruction - meaning 4 operations effectively.
As you can see, I have not reference any kernel functions API like you have mentioned it. Overall conceptual understanding comes first.