From: Julien Grall <julien.grall@linaro.org>
To: Tamas K Lengyel <tklengyel@sec.in.tum.de>
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Tim Deegan <tim@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
Xen-devel <xen-devel@lists.xen.org>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Jan Beulich <jbeulich@suse.com>, Keir Fraser <keir@xen.org>
Subject: Re: [PATCH V14 5/7] xen/arm: Instruction prefetch abort (X) mem_access event handling
Date: Fri, 27 Mar 2015 12:21:21 +0000 [thread overview]
Message-ID: <55154B41.2090807@linaro.org> (raw)
In-Reply-To: <CABfawhn_nY69_2pOXZZTVmOnmBZh_=Hn-0gcV__10+BLki0f4w@mail.gmail.com>
Hi Tamas,
On 27/03/15 08:32, Tamas K Lengyel wrote:
> + /*
> + * Flush the TLB to make sure the DTLB is clear before
> + * doing GVA->IPA translation. If we got here because of
> + * an entry only present in the ITLB, this translation may
> + * still be inaccurate.
> + */
> + flush_tlb_domain(current->__domain);
>
>
> flush TLB domain is very expensive, it flushes TLBs on every CPU.
> While you may only need a flush on the current CPU.
>
>
> Ack, there just isn't a function at the moment to do tlbflush only for a
> given cpu.
There is one function to flush the TLB only on the current CPU. See
flush_tlb_local.
flush_tlb_domain is an helper in order to flush TLB on another domain
than the current one.
> While I understand the argument behind the performance
> impact of the flush, any user of the mem_access system would IMHO prefer
> accuracy over performance. As I said before, this path seldom ever
> triggers without mem_access triggering it.
Without memaccess, we always inject a prefetch abort with the virtual
address. So we don't care about the flush TLB here.
>
>
> Although, on ARMv8, there is no possibility to flush only DTLB or
> ITLB for aarch64. You have to do both at the same time. So the
> problem you are describing can't happen. After reading the
> ID_MMFR2_EL1, I understand that Unified TLB is strongly advice on
> ARMv8 so any DTLB/ITLB flush would flush the unified TLB for aarch32
> guest.
>
>
> The problem I'm describing doesn't depend on having separate DTLB/ITLB
> flush operations available, albeit those making life a lot for a
> potential malicious in-guest kernel. There were no separate flush
> operations on x86 either and split-TLB poisoning was still a thing. The
> introduction of the sTLB is what made it less usable for malicious purposes.
What I was trying to say is given ID_MMFR2_EL1, I think ARMv8 only
support unified TLB. But I might be wrong...
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-03-27 12:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 22:05 [PATCH V14 0/7] Mem_access for ARM Tamas K Lengyel
2015-03-26 22:05 ` [PATCH V14 1/7] xen/arm: groundwork for mem_access support on ARM Tamas K Lengyel
2015-04-15 13:39 ` Ian Campbell
2015-03-26 22:05 ` [PATCH V14 2/7] xen/arm: Implement domain_get_maximum_gpfn Tamas K Lengyel
2015-04-08 13:23 ` Julien Grall
2015-04-08 13:38 ` Tamas K Lengyel
2015-04-08 13:42 ` Julien Grall
2015-04-08 13:47 ` Tamas K Lengyel
2015-04-08 13:49 ` Julien Grall
2015-03-26 22:05 ` [PATCH V14 3/7] xen/arm: Allow hypervisor access to mem_access protected pages Tamas K Lengyel
2015-04-08 14:33 ` Julien Grall
2015-04-08 15:57 ` Tamas K Lengyel
2015-04-08 16:07 ` Julien Grall
2015-04-15 13:48 ` Ian Campbell
2015-04-15 15:36 ` Tamas K Lengyel
2015-04-15 15:45 ` Ian Campbell
2015-04-16 9:04 ` Tim Deegan
2015-03-26 22:05 ` [PATCH V14 4/7] xen/arm: Data abort exception (R/W) mem_access events Tamas K Lengyel
2015-04-08 15:26 ` Julien Grall
2015-04-08 15:45 ` Tamas K Lengyel
2015-04-15 13:53 ` Ian Campbell
2015-03-26 22:05 ` [PATCH V14 5/7] xen/arm: Instruction prefetch abort (X) mem_access event handling Tamas K Lengyel
2015-03-26 23:21 ` Julien Grall
2015-03-27 8:32 ` Tamas K Lengyel
2015-03-27 12:21 ` Julien Grall [this message]
2015-03-27 15:52 ` Ian Campbell
2015-03-27 22:18 ` Tamas K Lengyel
2015-03-30 9:41 ` Ian Campbell
2015-03-30 15:14 ` Tamas K Lengyel
2015-03-30 15:24 ` Ian Campbell
2015-03-30 15:28 ` Tamas K Lengyel
2015-03-26 22:05 ` [PATCH V14 6/7] xen/arm: Enable mem_access on ARM Tamas K Lengyel
2015-03-26 22:05 ` [PATCH V14 7/7] tools/libxc: Allocate magic page for mem access " Tamas K Lengyel
2015-04-15 13:36 ` [PATCH V14 0/7] Mem_access for ARM Ian Campbell
2015-04-15 14:47 ` Tamas K Lengyel
2015-04-15 15:04 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55154B41.2090807@linaro.org \
--to=julien.grall@linaro.org \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=tklengyel@sec.in.tum.de \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.