Xen project Mailing List

Hi Julien,
It is expected that certain combinations of mem_access flags will put the domain into unstable condition, resulting in a crash or a hang. As Razvan mentioned, on x86 we can end up triggering EPT misconfiguration with the wrong set of flags. The user of the API is expected to know what he/she is doing in this regard, we don't do any enforcements or sanity checking on the Xen side.

As to the issue you describe, indeed that can happen. If the user marks a pagetable area non-readable/non-writable and the way ARM reports a walk for an instruction-fetch as an execute violation when it traps, it will hang the VM in a continuous violation state as no execute-violation was requested to be triggered on the gfn by the user. There are other situations where this can happen, as on ARM there is no such thing as execute-only memory, so any time the user requests memory to be execute-only or writable-executable will lead to problems like this - instruction fetch violation when the user only requested read-violations. But again, the users are expected to know what they are doing and perform their own sanity checks as appropriate.

Tamas

On Wed, Oct 5, 2016 at 2:06 PM, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> wrote:

Hello Julien,

> I have been looking into mem access support on ARM and I am wondering
> how we expect the flags MEM_ACCESS_{R,W,X} to be used when the
> permission fault is happening during stage 1 page table walk.
>
> For instance, if the fault is happening when the processor is loading an
> instruction, MEM_ACCESS_X will be set. However, the table walker may
> have failed because it is not possible to read the entry or update it
> (e.g dirty management).
>
> Let say the region has been protected read-write (I think it is
> XENMEM_access_x), it means that mem access will think it doesn't have to
> deal with the error and bail out. So the guest vCPU will get stuck
> forever repeating the stage-1 page table walk and getting an instruction
> fault.
>
> Similarly, the bit ESR_EL2.WnR during a data abort indicates whether the
> instruction was a load or store and not whether the page table walker
> was reading or writing the entry (see more details on [1]).
>
> So what is the expectation of the flags MEM_ACCESS_R (e.g
> npfec.read_access) and MEM_ACCESS_W (e.g npfec.write_access) for stage-2
> abort on stage-1 page table walk?
>
> Regards,
>
> [1] https://patchwork.kernel.org/patch/9356377/

I'm not sure what the right way forward is here, but I do know that
there's some "EPT misconfiguration" talk in the Intel SDM, specifically:

"25.2.3.1 EPT Misconfigurations

AN EPT misconfiguration occurs if any of the following is identified
while translating a guest-physical address:

• The value of bits 2:0 of an EPT paging-structure entry is either 010b
(write-only) or 110b (write/execute).

• The value of bits 2:0 of an EPT paging-structure entry is 100b
(execute-only) and this value is not supported by the logical processor.
Software should read the VMX capability MSR IA32_VMX_EPT_VPID_CAP to
determine whether this value is supported (see Appendix G.10).

• The value of bits 2:0 of an EPT paging-structure entry is not 000b
(the entry is present) and one of the following holds:

— A reserved bit is set. This includes the setting of a bit in the
range 51:12 that is beyond the logical processor’s physical-address width.

— The entry is the last one used to translate a guest physical address
(either an EPT PDE with bit 7 set to 1 or an EPT PTE) and the value of
bits 5:3 (EPT memory type) is 2, 3, or 7 (these values are reserved).

EPT misconfigurations result when an EPT paging-structure entry is
configured with settings reserved for future functionality.
Software developers should be aware that such settings may be used in
the future and that an EPT paging-structure entry that causes an EPT
misconfiguration on one processor might not do so in the future."

IIRC, an EPT misconfiguration usually triggers a triple fault in Xen.

Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

Re: [Xen-devel] Clarification regarding MEM_ACCESS_* flags usage