陷阱标志(TF)和监视器陷阱标志之间的区别? [英] Difference between trap flag (TF) and monitor trap flag?
问题描述
GDB之类的调试功能通过设置eflags寄存器的TF标志来工作，该标志会在处理器每次执行指令后导致异常，让gdb之类的工具来控制调试.要执行相同的操作，您需要设置一个称为MONITOR TRAP FLAG的标志(当前intel软件手册3c的第15页)，这将在每条向管理程序进行任意调试的指令执行后，导致虚拟计算机退出(VMEXIT).
虚拟机监控程序几乎可以设置VM(来宾)的任何位/寄存器.当体系结构(EFLAG)中已经存在这样的标记时，为什么在VMCS(虚拟Macine控制结构)中需要一个单独的标记?
我在某处读到，原因是如果使用EFLAGS，则来宾可以将VMM的(管理程序)意图覆盖为单步执行.
A:如果没有控制权，那么模拟硬件又有什么意义呢?
B:我遇到一个需要设置BTF(分支陷阱标志)的问题(PG 689 vOLUME 3a INTEL软件手册).在正常情况下，这会导致对每条分支指令进行DEBUG EXCEPTION调试，但是由于我希望在VM上进行调试，因此无法确定在VMCS中设置哪一位.似乎没有像单步执行那样的直接方法.有人可以让我知道是否有其他方法可以使用其他方法来做同样的事情?
谢谢
否，没有分支监视器陷阱标志.
英特尔可能制造一个，但没有.
详细信息
让我们首先了解一下术语:
[请注意，所有这些仅与Intel x86相关]
陷阱标志(TF)
如问题中所述，在执行指令后导致#DBG(通过异常0x1捕获). 通过RFLAGS的第8位进行控制.
分支陷阱标志(BTF)
TLDR:BTF修改TF的行为，使其仅在分支上触发异常.
自2016年4月版的Intel SDM:
当软件同时设置IA32_DEBUGCTL MSR中的BTF标志(位1)时 和EFLAGS寄存器中的TF标志，处理器会生成一个 仅在导致 分支.[1]该机制允许调试器进行单步控制 由分支机构引起的转移.这种单步执行"有助于 在指令之前将错误隔离到特定的代码块 单步执行进一步缩小了搜索范围.处理器清除 生成调试异常时的BTF标志.调试器必须设置 恢复程序执行继续之前的BTF标志 单步执行分支.
[1] CALL，IRET和JMP的执行不会导致任务切换 导致单步调试异常(与BTF的值无关) 旗帜).调试器需要在切换到任务时进行调试例外 应该在该任务的TSS中设置T标志(调试陷阱标志).看 第7.2.1节任务状态段(TSS)".
监视器陷阱标志(MTF)
MTTF是VMCS中的一位，它在来宾中的某些指令边界上触发监视器陷阱标志VMEXIT.
通常来说，每当来宾进行前进时，都会发生退出，并且没有任何主机比MTF VMEXIT拥有更高的优先级.有一些奇怪的情况，例如REP MOV(可以被中断的指令)和SMI(对于主机OS不可见的中断).有关详细信息，请参阅SDM的监视器陷阱标志"部分(2016年4月为25.5.2).
响应
为什么我们在VMCS中需要一个单独的标志(虚拟Macine控件 结构)在架构中已经存在此类标志时 (EFLAG)?
主机和来宾状态需要分开.如果要调试运行GDB的来宾，则主机需要能够触发VMEXIT，而不是来宾内的异常.请注意，设置了陷阱标志后，默认值为在当前上下文中引发异常(如果在客户机中运行，则为客户机；如果在主机中运行，则为主机).
通过使用VMCS中的异常位图强制设置来宾的TF并根据调试异常配置VMEXIT，主机可以尝试不使用MTF进行调试.不幸的是，如果guest虚拟机也启用了调试异常，则主机无法通过任何明确的方式来知道调试异常属于谁(如果我没记错的话，就无法退出对RFLAGS的写操作). MTF的存在使调试运行调试器的VM成为可能.
...有人可以让我知道是否有某种方法可以做同样的事情 用其他方式?
没有分支监视器陷阱标志.您可以通过查看来宾的RIP(应在VMCS中)的解码指令来实现等效的功能，但这将需要大量额外的VMEXITS.显然，这并不理想.
如果要在进入访客之前设置BTF，事情会很快变得混乱.它将被视为来宾的BTF，而不是与主机相关的BTF.如果您还在VMCS中设置MTF，则BTF将不会延迟MTF VMEXIT.另一方面，它将延迟来宾的下一个调试陷阱.
如果下一个guest虚拟机VMEXIT出现，则BTF将被破坏，如果尚未通过调试异常将其清除(IA32_DEBUGCTL在退出时被清除).您可以使用MSR LOAD/STORE列表保存该值，但这并不能完成很多工作.
Debugging features like GDB work by setting the TF flag of eflags register which causes an exception after every execution of instruction by the processor, letting tools like gdb control over the debugging.When we are running a virtual machine Ex in case of kvm to do the same thing you need to set a flag called the MONITOR TRAP FLAG (pg 15 of current intel software manual 3c), which will cause the virtual macine to EXIT (VMEXIT) after every instruction giving debugging abitily to the hypervisor.
The hypervisor can set almost any bit/register of the VM(guest). Why do we need a seperate flag in the VMCS (virtual Macine control Structure) when such a flag is already present in the architecture (EFLAG)??
I read somewhere that, the reason for this is that guest can override VMM’s (hypervisor) intention to single step if EFLAGS were used.
A:Whats the point of emulating hardware if you don't have control??
B: I am facing a issue where I need to set BTF (branch Trap Flag)(PG 689 vOLUME 3a INTEL sotfware manual). In a normal scenario this cause DEBUG EXCEPTION on every branch instruction but since I want to this on a VM, I am not able to figure which bit to set in the VMCS. There seems to be no direct way doing this like in the case of single stepping. Can anyone let me know If there some way to do the same thing using other means ?
Thanks
No, there is no Branch Monitor Trap Flag.
Intel could probably make one, but hasn't.
Details
Let's first go through and define terms:
[Note that all of this is only relevant to Intel x86]
Trap Flag (TF)
As described in the question, causes #DBG after the execution of an instruction (Traps through exception 0x1). Controlled using bit 8 of RFLAGS.
Branch Trap Flag (BTF)
TLDR: The BTF modifies the behavior of the TF to only trigger exceptions on branches.
From the April 2016 Edition of the Intel SDM:
When software sets both the BTF flag (bit 1) in the IA32_DEBUGCTL MSR and the TF flag in the EFLAGS register, the processor generates a single-step debug exception only after instructions that cause a branch.[1] This mechanism allows a debugger to single-step on control transfers caused by branches. This "branch single stepping" helps isolate a bug to a particular block of code before instruction single-stepping further narrows the search. The processor clears the BTF flag when it generates a debug exception. The debugger must set the BTF flag before resuming program execution to continue single-stepping on branches.
[1] Executions of CALL, IRET, and JMP that cause task switches never cause single-step debug exceptions (regardless of the value of the BTF flag). A debugger desiring debug exceptions on switches to a task should set the T flag (debug trap flag) in the TSS of that task. See Section 7.2.1, "Task-State Segment (TSS)."
Monitor Trap Flag (MTF)
The MTF is a bit in the VMCS that triggers Monitor Trap Flag VMEXITs on certain instruction boundaries while in a guest.
Generally speaking, the exit occurs whenever the guest is making forward progress, and nothing occurs host side that would be of higher priority than the MTF VMEXIT. There are weird edge cases, like REP MOV (an instruction which can be interrupted) and SMIs (Interrupts that are invisible-ish to the host OS). See the Monitor Trap Flag section of the SDM for specifics (25.5.2 in April 2016).
Responses
Why do we need a seperate flag in the VMCS (virtual Macine control Structure) when such a flag is already present in the architecture (EFLAG)?
Host and Guest State need to be separate. If you are debugging a guest that is running GDB, the host needs to be able to trigger VMEXITs, rather than exceptions within the guest. Note that when the trap flag is set, the default is to fire an exception within the current context (the guest's if you are running in the guest, the host's if you are running in the host).
The host could attempt to debug without using the MTF by forcibly setting the guest's TF and configuring VMEXITs on debug exceptions using the exception bitmaps in the VMCS. Unfortunately, if the guest has also enabled debug exceptions, there is no clean way for the host to know who the debug exception belongs to (If I recall correctly, there is no way to exit on writes to RFLAGS). The existence of MTF makes it possible to debug a VM running a debugger.
... Can anyone let me know If there some way to do the same thing using other means?
There is no Branch Monitor Trap Flag. You could implement something equivalent by looking at the decoded instruction at the guest's RIP (which should be in the VMCS), but that will require a bunch of extra VMEXITS. Obviously, that's not ideal.
If you were to set the BTF before entering the guest, things will get messy fast. It will be perceived as the guest's BTF rather than a BTF related to the host. If you also set the MTF in the VMCS, the BTF will not delay the MTF VMEXIT. On the other hand, it will delay the guest's next debug trap.
Whenever the guest VMEXITs next, the BTF will get clobbered, if it was not already cleared by a debug exception (IA32_DEBUGCTL is cleared on exit). You could save the value using the MSR LOAD/STORE lists, but that doesn't accomplish much.
这篇关于陷阱标志(TF)和监视器陷阱标志之间的区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
