Intel EPT violation clarification

[cianfa72]

Hi,

I'm digging into kvm code in order to better understand how EPT is used to map GPA -> HPA in a basic virtualization scenario. Reading Intel SDM vol.3 I've not a clear understanding about the EPT violation exit qualification as follows (see Table 27-7 bit 8 )

If bit 7 is 1:
• Set if the access causing the EPT violation is to a guest-physical address that is the translation of a linear
address.
• Clear if the access causing the EPT violation is to a paging-structure entry as part of a page walk or the
update of an accessed or dirty bit.
Reserved if bit 7 is 0 (cleared to 0).

AFAIU bit 8 is set by the processor if the EPT violation is due to an access to any of the entry of guest paging hierarchy structures (PML4T, PDPT, PT or PG depending of guest translation model used) whereas it is not (clear) only when the translation GVA->GPA has been succesful (it has been able to accomplish the translation) and now the processor is trying to access to the obtained GPA (resulting in an EPT violation)

Does it sound right ? Thanks

[dchapiesky]

A little googling turns up that

"whereas it is not (clear) only when the translation GVA->GPA has been succesful (it has been able to accomplish the translation) and now the processor is trying to access to the obtained GPA (resulting in an EPT violation)"

appears to be an edge case but can still happen. I have recommended the Intel Kernel Guard (ikgt) project in other threads on osdev but this time I really mean it...

check out ikgt ept related code here... https://github.com/01org/ikgt-core/blob ... /ept/ept.c

ikgt is a ring -1 hypervisor designed to allow monitoring of vm events... such as EPT violations... worth a look for you if only to compare against KVM

cheers

[cianfa72]

I'm sorry... but I believe my previous statements have to be exchanged as follows:

bit 8 is set by the processor if the translation GVA->GPA has been successful (it has been able to accomplish the GVA->GPA translation) and now the processor is trying to access to the obtained GPA resulting in an EPT violation, whereas is not (clear) only when EPT violation is due to an access to any of the entry of guest paging hierarchy structures (PML4T, PDPT, PT or PG depending of guest translation model used) during guest page walking

[cianfa72]

...digging into kvm exit with EPT_VIOLATION reason, I've noted the following:

Code: Select all

root@unl02:~# root@unl02:~# trace-cmd start -e kvm:kvm_exit -f 'exit_reason == 48' -e kvm:kvm_page_fault
/sys/kernel/debug/tracing/events/kvm/kvm_exit/filter
/sys/kernel/debug/tracing/events/kvm/kvm_page_fault/filter
root@unl02:~# trace-cmd show
# tracer: nop
#
# entries-in-buffer/entries-written: 8/8   #P:48
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
           <...>-41584 [008] .... 579988.037495: kvm_exit: reason EPT_VIOLATION rip 0x9a2d6ac info 181 0
           <...>-41584 [008] .... 579988.037498: kvm_page_fault: address bfe28dea error_code 181
           <...>-41584 [008] .... 579988.037554: kvm_exit: reason EPT_VIOLATION rip 0x8977012 info 183 0
           <...>-41584 [008] .... 579988.037555: kvm_page_fault: address bfc4745a error_code 183

kvm-based VM is running a guest OS using 4KB (or even 2MB) page size so I would expect guest physical address (gpa) reported by kvm exit ept_violation handler (via trace_kvm_page_fault tracepoint) should have last 3 hex digits equal to the last 3 hex digits of guest RIP value into VMCS' VM-exit "exit reason" field.

According kvm source code (http://lxr.free-electrons.com/source/arch/x86/kvm/vmx.c), error code reported there (e.g. 181 or 183) should not point to an EPT violation occurrence due to an access to any of guest paging hierarchy entry (PML4T, PDPT, PT or PG depending of guest translation model used) during guest page walking.....thus, why we don not get the same values for the last 3 hex digits ?

[Nable]

If the fault is caused by data access (i.e. not by the fetch of the next instruction), then fault address has nothing to do with the address of the instruction that was accessing some data area.

[cianfa72]

If the fault is caused by data access (i.e. not by the fetch of the next instruction), then fault address has nothing to do with the address of the instruction that was accessing some data area.

you are definitely right !
For instance when the error code reported (184) point to the reason "the access causing the EPT violation was an instruction fetch" (see bit position 2 Table 27-7 Intel SDM vol.3) the last 3 hex digits are actually the same (see below):

Code: Select all

           <...>-41584 [009] .... 666226.558540: kvm_exit: reason EPT_VIOLATION rip 0x4218ac3 info 184 0
           <...>-41584 [009] .... 666226.558541: kvm_page_fault: address 70a71ac3 error_code 184

Just to be sure I understand correctly what you said, suppose for example the EPT violation is caused by a data access like this:

Code: Select all

mov [ebp + 4], eax

here the faulting data access address (ebp + 4) has nothing to do with the address of the mov instruction itself.

Do I get it right ?

[Nable]

Do I get it right ?

Yes, that's exactly what I wanted to say.