Re: [Xen-devel] [PATCH V13 5/7] xen/arm: Instruction prefetch abort (X) mem_event handling

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Mon, Mar 23, 2015 at 5:22 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> On Mon, 2015-03-23 at 16:47 +0100, Tamas K Lengyel wrote:
>>
>>
>> On Mon, Mar 23, 2015 at 4:18 PM, Ian Campbell
>> <ian.campbell@xxxxxxxxxx> wrote:
>>         On Mon, 2015-03-23 at 15:15 +0000, Ian Campbell wrote:
>>         > _But_ I suppose you are not really worried about the guest
>>         doing a PT
>>         > update, but rather xenaccess playing games with the stage 2
>>         behind the
>>         > guest's back, which might require us to do some TLB
>>         shootdowns, and we'd
>>         > have to assume both I-TLB and D-TLB since we don't know what
>>         the guest
>>         > has in those pages.
>>
>>         When we change the p2m we do a tlbi vmalle1is, so regardless
>>         of whether
>>         split tlb is a thing we are flushing everything, so we should
>>         be good
>>         from a stage 2 PoV.
>>
>>
>> When we apply p2m changes we do indeed flush the TLB. I do actually
>> worry about a potential malicious in-guest kernel playing tricks with
>> its pagetables which may have happened after the p2m changes were
>> applied. The xen-access permissions are applied based on IPAs. Say I
>> want to be notified when a specific API is being called, so I walk the
>> guest-pagestables and set a trap at the page the IPA is one. If the
>> malicious guest kernel wants to avoid triggering the xen-access
>> notifications, it could theoretically prime its tables and perform the
>> right accesses so that the iTLB still has the mapping I wanted to trap
>> with xen-access, but the dTLB has a different mapping. The instruction
>> abort trap will happen but in Xen I will see the mapping according to
>> the dTLB, thus the radix-tree lookup fails and the trap is injected
>> back into the guest.
>
> But in that case the guest will take a trap, so what has it gained other
> than a spurious trap?

Bypassing the notification being sent to the subscriber application
about the trap.

>
> I can't see anything in the TLB chapter of the ARMv8 ARM which suggests
> split TLBs are possible in AArch64 mode, and the AArch32 refs look like
> backwards compat stuff to me.
>
> The ARMv7 ARM does mention the split, but only to say that the
> distinction between the ITLB and DTLB maintenance operations is
> deprecated and that modern TLB ops do not support the distinction. It's
> not 100% unambiguous about whether split TLBs themselves are allowed in
> ARMv7 though, and in particular I'm not sure what impact the addition of
> the LPAE and virtualisation extensions will have had on these
> requirements. I also can't quite tell if split TLB is allowed on VMSA
> systems, or if it is PMSA only.
>
> As you might imagine I'm not keen on adding TLB flushes "just in case",
> so I would really like to see some good references to the architecture
> specs before adding a flush on this path.
>
> Ian.

IMHO a TLB flush in this path is low impact for systems that don't use
xen-access. As far as which hardware supports it, I see the following
for A53 
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500f/BIIJFHJD.html):

10-entry fully-associative instruction micro TLB.
10-entry fully-associative data micro TLB.

For A57 
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500f/BIIJFHJD.html):

48-entry fully-associative L1 instruction TLB.
32-entry fully-associative L1 data TLB for data load and store pipelines.

Tamas

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