Clarification regarding MEM_ACCESS_* flags usage

Clarification regarding MEM_ACCESS_* flags usage

[Julien Grall]

Hello Tamas and Ravzan,

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/

-- 
Julien Grall

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

Re: Clarification regarding MEM_ACCESS_* flags usage

[Razvan Cojocaru]

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@lists.xen.org
https://lists.xen.org/xen-devel

Re: Clarification regarding MEM_ACCESS_* flags usage

[Tamas K Lengyel]

[-- Attachment #1.1: Type: text/plain, Size: 4386 bytes --]

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@bitdefender.com>
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@lists.xen.org
> https://lists.xen.org/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 5258 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: Clarification regarding MEM_ACCESS_* flags usage

[Julien Grall]

On 05/10/2016 13:23, Tamas K Lengyel wrote:
> 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.

I think the problem I described is neither the fault of the user, 
neither a misconfiguration of the page table. Let me clarify it.

The user can purposefully restrict the access to stage-1 page table to 
detect when the OS is modifying them. By side effect, this will also 
impact the page table walker.

A prefetch abort (e.g when an error occurs when the processor is trying 
to load the instruction) can either occur during a stage-1 page table 
walk (e.g the underlying memory of stage-1 page table has been 
protected) or because the permission in the stage-2 entry has been 
restricted.

In the case of the latter, this will always be because the memory is not 
executable. However, for the former may happen if the page table walker 
(i.e the MMU) is reading/writing the entry.

However, Xen ARM today is always considering that a prefetch abort will 
happen because it was not possible to execute the instruction.

I requested clarification about the flags because we need to fix this 
valid issue. From the usage on ARM and in the vm event app, it is not 
clear how those flags should be used.

Regards,

-- 
Julien Grall

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

Re: Clarification regarding MEM_ACCESS_* flags usage

[Razvan Cojocaru]

On 10/05/2016 11:54 PM, Julien Grall wrote:
> 
> 
> On 05/10/2016 13:23, Tamas K Lengyel wrote:
>> 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.
> 
> I think the problem I described is neither the fault of the user,
> neither a misconfiguration of the page table. Let me clarify it.
> 
> The user can purposefully restrict the access to stage-1 page table to
> detect when the OS is modifying them. By side effect, this will also
> impact the page table walker.
> 
> A prefetch abort (e.g when an error occurs when the processor is trying
> to load the instruction) can either occur during a stage-1 page table
> walk (e.g the underlying memory of stage-1 page table has been
> protected) or because the permission in the stage-2 entry has been
> restricted.
> 
> In the case of the latter, this will always be because the memory is not
> executable. However, for the former may happen if the page table walker
> (i.e the MMU) is reading/writing the entry.
> 
> However, Xen ARM today is always considering that a prefetch abort will
> happen because it was not possible to execute the instruction.
> 
> I requested clarification about the flags because we need to fix this
> valid issue. From the usage on ARM and in the vm event app, it is not
> clear how those flags should be used.

I understand. FWIW, I find it better to have the most precise type of
event sent, i.e. in your case if the application gets a read-only page
fault event it would then be able to do something about it (for example,
lift the restrictions on the page), whereas if it would get an execute
denied event in this case, allowing execution on that page would not
solve the issue and leave the guest in an infinite loop, as you say. The
problem here is that the application never gets a chance to do the right
thing even if it wants to, and is capable of that.

So I'm all for properly differentiating between these two cases, unless
the ARM SDM disagrees or there's some reason why this is unfeasible.


Thanks,
Razvan

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

Re: Clarification regarding MEM_ACCESS_* flags usage

[Tamas K Lengyel]

[-- Attachment #1.1: Type: text/plain, Size: 4519 bytes --]

On Thu, Oct 6, 2016 at 3:59 AM, Razvan Cojocaru <rcojocaru@bitdefender.com>
wrote:

> On 10/05/2016 11:54 PM, Julien Grall wrote:
> >
> >
> > On 05/10/2016 13:23, Tamas K Lengyel wrote:
> >> 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.
> >
> > I think the problem I described is neither the fault of the user,
> > neither a misconfiguration of the page table. Let me clarify it.
> >
> > The user can purposefully restrict the access to stage-1 page table to
> > detect when the OS is modifying them. By side effect, this will also
> > impact the page table walker.
> >
> > A prefetch abort (e.g when an error occurs when the processor is trying
> > to load the instruction) can either occur during a stage-1 page table
> > walk (e.g the underlying memory of stage-1 page table has been
> > protected) or because the permission in the stage-2 entry has been
> > restricted.
> >
> > In the case of the latter, this will always be because the memory is not
> > executable. However, for the former may happen if the page table walker
> > (i.e the MMU) is reading/writing the entry.
> >
> > However, Xen ARM today is always considering that a prefetch abort will
> > happen because it was not possible to execute the instruction.
> >
> > I requested clarification about the flags because we need to fix this
> > valid issue. From the usage on ARM and in the vm event app, it is not
> > clear how those flags should be used.
>
> I understand. FWIW, I find it better to have the most precise type of
> event sent, i.e. in your case if the application gets a read-only page
> fault event it would then be able to do something about it (for example,
> lift the restrictions on the page), whereas if it would get an execute
> denied event in this case, allowing execution on that page would not
> solve the issue and leave the guest in an infinite loop, as you say. The
> problem here is that the application never gets a chance to do the right
> thing even if it wants to, and is capable of that.
>
> So I'm all for properly differentiating between these two cases, unless
> the ARM SDM disagrees or there's some reason why this is unfeasible.
>

The issue I see here is that if the CPU itself traps as an instruction
fetch violation because the pagetable was unreadable, then sending out a
vm_event with a MEM_ACCESS_* type other then what the hardware reported
will complicate things significantly. It would require the mem_access
system in Xen to further check when there is no violating mem_access X
setting found to check if all pages used for translating the PC were
readable or not. This would require us to walk through the currently active
pagetable and check if any of those have a restricted mem_access setting,
and if one is found send out a notification with MEM_ACCESS_R flag set.
This is pretty complicated considering all the different page types the OS
could use. I rather not move this logic into Xen but have the user
implement it if it is needed. For example, if the user wants to make the
pages where pagetables reside unreadable with mem_access then would also
have to mark all pages contained in that pagetable non-executable with
mem_access. So since the current setup can be worked with, I rather not
complicated the Xen side and just have it accurately report the trap as it
received it from the CPU itself.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 5327 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: Clarification regarding MEM_ACCESS_* flags usage

[Julien Grall]

On 06/10/2016 09:39, Tamas K Lengyel wrote:
>
>
> On Thu, Oct 6, 2016 at 3:59 AM, Razvan Cojocaru
> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
>
>     On 10/05/2016 11:54 PM, Julien Grall wrote:
>     >
>     >
>     > On 05/10/2016 13:23, Tamas K Lengyel wrote:
>     >> 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.
>     >
>     > I think the problem I described is neither the fault of the user,
>     > neither a misconfiguration of the page table. Let me clarify it.
>     >
>     > The user can purposefully restrict the access to stage-1 page table to
>     > detect when the OS is modifying them. By side effect, this will also
>     > impact the page table walker.
>     >
>     > A prefetch abort (e.g when an error occurs when the processor is
>     trying
>     > to load the instruction) can either occur during a stage-1 page table
>     > walk (e.g the underlying memory of stage-1 page table has been
>     > protected) or because the permission in the stage-2 entry has been
>     > restricted.
>     >
>     > In the case of the latter, this will always be because the memory
>     is not
>     > executable. However, for the former may happen if the page table
>     walker
>     > (i.e the MMU) is reading/writing the entry.
>     >
>     > However, Xen ARM today is always considering that a prefetch abort
>     will
>     > happen because it was not possible to execute the instruction.
>     >
>     > I requested clarification about the flags because we need to fix this
>     > valid issue. From the usage on ARM and in the vm event app, it is not
>     > clear how those flags should be used.
>
>     I understand. FWIW, I find it better to have the most precise type of
>     event sent, i.e. in your case if the application gets a read-only page
>     fault event it would then be able to do something about it (for example,
>     lift the restrictions on the page), whereas if it would get an execute
>     denied event in this case, allowing execution on that page would not
>     solve the issue and leave the guest in an infinite loop, as you say. The
>     problem here is that the application never gets a chance to do the right
>     thing even if it wants to, and is capable of that.
>
>     So I'm all for properly differentiating between these two cases, unless
>     the ARM SDM disagrees or there's some reason why this is unfeasible.
>
>
> The issue I see here is that if the CPU itself traps as an instruction
> fetch violation because the pagetable was unreadable, then sending out a
> vm_event with a MEM_ACCESS_* type other then what the hardware reported
> will complicate things significantly. It would require the mem_access
> system in Xen to further check when there is no violating mem_access X
> setting found to check if all pages used for translating the PC were
> readable or not. This would require us to walk through the currently
> active pagetable and check if any of those have a restricted mem_access
> setting, and if one is found send out a notification with MEM_ACCESS_R
> flag set. This is pretty complicated considering all the different page
> types the OS could use. I rather not move this logic into Xen but have
> the user implement it if it is needed. For example, if the user wants to
> make the pages where pagetables reside unreadable with mem_access then
> would also have to mark all pages contained in that pagetable
> non-executable with mem_access. So since the current setup can be worked
> with, I rather not complicated the Xen side and just have it accurately
> report the trap as it received it from the CPU itself.

You still don't get my point. The fact that the traps is an instruction 
fetch violation is valid because the stage-1 page table walk happened 
whilst the processor was trying to fetch the instruction.

If the trap happened because of the stage-1 page table walk fault, the 
trap will report the VA of the page table and s1ptw will be set. The VA 
will *NOT* be the address of the instruction. Give a look to HPFAR_EL2 
(D7.2.34 ARM DDI 0487A.j) for more details.

So setting the flag MEM_ACCESS_X is just completely wrong. I would be 
surprised that x86 set MEM_ACCESS_X if the fault happened during page 
table walk...

Anyway, we have s1ptw bit in hand, so fixing the problem is really easy.
Asking the user to set the underlying memory of stage-1 page table as 
non-executable would not work because the page table walker does not 
care about this bit. Only read and write will affect the walker.

Regards,

-- 
Julien Grall

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

Re: Clarification regarding MEM_ACCESS_* flags usage

[Tamas K Lengyel]

[-- Attachment #1.1: Type: text/plain, Size: 6754 bytes --]

On Thu, Oct 6, 2016 at 11:10 AM, Julien Grall <julien.grall@arm.com> wrote:

>
>
> On 06/10/2016 09:39, Tamas K Lengyel wrote:
>
>>
>>
>> On Thu, Oct 6, 2016 at 3:59 AM, Razvan Cojocaru
>> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
>>
>>     On 10/05/2016 11:54 PM, Julien Grall wrote:
>>     >
>>     >
>>     > On 05/10/2016 13:23, Tamas K Lengyel wrote:
>>     >> 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.
>>     >
>>     > I think the problem I described is neither the fault of the user,
>>     > neither a misconfiguration of the page table. Let me clarify it.
>>     >
>>     > The user can purposefully restrict the access to stage-1 page table
>> to
>>     > detect when the OS is modifying them. By side effect, this will also
>>     > impact the page table walker.
>>     >
>>     > A prefetch abort (e.g when an error occurs when the processor is
>>     trying
>>     > to load the instruction) can either occur during a stage-1 page
>> table
>>     > walk (e.g the underlying memory of stage-1 page table has been
>>     > protected) or because the permission in the stage-2 entry has been
>>     > restricted.
>>     >
>>     > In the case of the latter, this will always be because the memory
>>     is not
>>     > executable. However, for the former may happen if the page table
>>     walker
>>     > (i.e the MMU) is reading/writing the entry.
>>     >
>>     > However, Xen ARM today is always considering that a prefetch abort
>>     will
>>     > happen because it was not possible to execute the instruction.
>>     >
>>     > I requested clarification about the flags because we need to fix
>> this
>>     > valid issue. From the usage on ARM and in the vm event app, it is
>> not
>>     > clear how those flags should be used.
>>
>>     I understand. FWIW, I find it better to have the most precise type of
>>     event sent, i.e. in your case if the application gets a read-only page
>>     fault event it would then be able to do something about it (for
>> example,
>>     lift the restrictions on the page), whereas if it would get an execute
>>     denied event in this case, allowing execution on that page would not
>>     solve the issue and leave the guest in an infinite loop, as you say.
>> The
>>     problem here is that the application never gets a chance to do the
>> right
>>     thing even if it wants to, and is capable of that.
>>
>>     So I'm all for properly differentiating between these two cases,
>> unless
>>     the ARM SDM disagrees or there's some reason why this is unfeasible.
>>
>>
>> The issue I see here is that if the CPU itself traps as an instruction
>> fetch violation because the pagetable was unreadable, then sending out a
>> vm_event with a MEM_ACCESS_* type other then what the hardware reported
>> will complicate things significantly. It would require the mem_access
>> system in Xen to further check when there is no violating mem_access X
>> setting found to check if all pages used for translating the PC were
>> readable or not. This would require us to walk through the currently
>> active pagetable and check if any of those have a restricted mem_access
>> setting, and if one is found send out a notification with MEM_ACCESS_R
>> flag set. This is pretty complicated considering all the different page
>> types the OS could use. I rather not move this logic into Xen but have
>> the user implement it if it is needed. For example, if the user wants to
>> make the pages where pagetables reside unreadable with mem_access then
>> would also have to mark all pages contained in that pagetable
>> non-executable with mem_access. So since the current setup can be worked
>> with, I rather not complicated the Xen side and just have it accurately
>> report the trap as it received it from the CPU itself.
>>
>
> You still don't get my point. The fact that the traps is an instruction
> fetch violation is valid because the stage-1 page table walk happened
> whilst the processor was trying to fetch the instruction.
>
> If the trap happened because of the stage-1 page table walk fault, the
> trap will report the VA of the page table and s1ptw will be set. The VA
> will *NOT* be the address of the instruction. Give a look to HPFAR_EL2
> (D7.2.34 ARM DDI 0487A.j) for more details.
>
> So setting the flag MEM_ACCESS_X is just completely wrong. I would be
> surprised that x86 set MEM_ACCESS_X if the fault happened during page table
> walk...
>

If the hardware traps it as an instruction fetch violation then no, it is
not wrong, it is what the hardware reports it as. Hiding this information
is not OK.


>
> Anyway, we have s1ptw bit in hand, so fixing the problem is really easy.
> Asking the user to set the underlying memory of stage-1 page table as
> non-executable would not work because the page table walker does not care
> about this bit. Only read and write will affect the walker.
>

That's not what I said - I said walk the pagetables and change the settings
on the pages pointed to by the table. But as you say if the VA reported is
not the address of the instruction, but rather the address of the page in
the pagetable where the walk failed, then indeed checking for R permission
restriction when the ptw bit is set should be relatively easy and we could
report the event as instruction fetch violation _and_ read access
violation. Reporting it as only read violation is not OK though.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 8161 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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