From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] arm/mm: L2CC shared mutex with ARM TZ
Date: Wed, 14 Nov 2012 17:22:16 +0000 [thread overview]
Message-ID: <20121114172216.GG16215@arm.com> (raw)
In-Reply-To: <0154077FE026E54BB093CA7EB3FD1AE32DB61E4CC7@SAFEX1MAIL3.st.com>
On Wed, Nov 14, 2012 at 10:15:46AM +0000, Etienne CARRIERE ST wrote:
> > Tue 11-13-2012 8:23 PM
> > From: Abhimanyu Kapur <abhimanyu.kapur@outlook.com>
> >
> > > Secure code in TrustZone space may need to perform L2 cache
> > > maintenance operations. A shared mutex is required to synchronize
> > > linux l2cc maintenance and TZ l2cc maintenance.
> >
> > If you are using PL310 with thrustzone support then the L2 cache lines
> > are secure bit tagged ; your design should be such that the secure (TZ)
> > side only does operations on secure cache lines and non-secure side
> > does operations only on non-secure cache lines. So each entity (TZ
> > and nonTZ) if maintains their own cache and ensures integrity before
> > switching over via monitor, this might not be needed.
>
> I don't think 2 cores can safely write the LX20_CLEAN/INV_LINE_PA
> registers of the PL310 at the same time, even if targeting different
> lines.
Actually for the clean/invalidate operations by PA you can safely write
the registers from two different processors as they get serialised by
the hardware. What you don't get is protection around the background
operations (clean/inv by way). I think it depends on how the PL310 is
wired on your hardware but trying to do a PA operation while a
background one is in progress would trigger an external abort.
So the NS world could simply start a background cache operation without
taking the lock while the secure world thinks that it has the lock and
tries to do a PA operation which would abort.
My advise is to simply ignore the shared locking and only do atomic PA
operations on the secure side. The secure side also needs to poll for
the completion of any background operation that was started in
non-secure world. Of course, there is still a race, in which case,
depending on the hardware implementation, you would need to trap any
possible aborts while in secure mode when writing the PL310 registers.
--
Catalin
next prev parent reply other threads:[~2012-11-14 17:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-13 16:08 [PATCH 1/2] arm/mm: L2CC shared mutex with ARM TZ Etienne CARRIERE
2012-11-13 17:07 ` Russell King - ARM Linux
2012-11-14 9:18 ` Etienne CARRIERE ST
2012-11-14 9:51 ` Will Deacon
2012-11-14 10:40 ` Etienne CARRIERE ST
2012-11-14 10:21 ` Russell King - ARM Linux
2012-11-14 10:45 ` Etienne CARRIERE ST
2012-11-14 10:50 ` Russell King - ARM Linux
2012-11-14 11:02 ` Etienne CARRIERE ST
2012-11-13 17:17 ` Dave Martin
2012-11-13 19:22 ` Abhimanyu Kapur
2012-11-14 10:15 ` Etienne CARRIERE ST
2012-11-14 17:22 ` Catalin Marinas [this message]
2012-11-15 13:46 ` Etienne CARRIERE ST
2012-11-15 13:55 ` Catalin Marinas
2012-11-15 14:10 ` Etienne CARRIERE ST
2012-11-14 10:13 ` Etienne CARRIERE ST
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=20121114172216.GG16215@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).