[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-omap
Subject:    Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Noki
From:       Pali =?utf-8?q?Roh=C3=A1r?= <pali.rohar () gmail ! com>
Date:       2015-01-31 19:09:58
Message-ID: 201501312009.58483 () pali
[Download RAW message or body]

On Saturday 31 January 2015 15:38:28 Matthijs van Duin wrote:
> On Sunday 08 December 2013 00:22:06 Tony Lindgren wrote:
> > * Sebastian Reichel <sre@ring0.de> [131207 15:04]:
> > > On Sat, Dec 07, 2013 at 01:11:37PM -0800, Tony Lindgren 
> > > wrote:
> > > > > I asked Pali to send me his copy of the updated NOLO
> > > > > bootloader, so that I can test this. I just checked
> > > > > the omap documentation (I only have access to the
> > > > > public one) and crypto related stuff is not
> > > > > documented for the L3_PM_READ_PERMISSION register.
> > > > > There are a couple of reserved bits, which may be
> > > > > used for this, though.
> > > > > 
> > > > > I also CC'd Joel Fernandes, since he worked on the
> > > > > driver before and may have access to the
> > > > > documentation.
> > > > 
> > > > Looks like at least the 36xx public version referenced
> > > > here has them:
> > > > 
> > > > http://www.spinics.net/lists/linux-omap/msg21857.html
> > > > 
> > > > I'd assume the registers are the same for 34xx since we
> > > > don't have them defined separately in the kernel.
> > > 
> > > I can't find it in the omap36xx documentation either.
> > > Maybe I search at the wrong position.
> 
> I've checked a few of the oldest (in case it was later
> removed) and newest (in case it was later added) omap3-series
> public TRMs I have, none of them list the aes module or
> associated interconnect info. The region is either "reserved"
> or just silently skipped over. The practice of pretending
> something doesn't exist in the TRM while simultaneously
> releasing a linux driver continues to puzzle me.
> 
> > > I tried to find something crypto related in
> > > 
> > > Table 9-89. L3_PM_READ_PERMISSION_i
> > 
> > Hmm maybe it's done based on the address in
> > L3_PM_ADDR_MATCH_k?
> 
> According to the address (aes@480c5000) it's attached to the
> L4-Core interconnect, so why would an L3 firewall be
> involved?  Its access control would be configured in the
> L4-Core AP (2KB @ 0x48040000), and since they have an
> integrated memory map you'd automatically know which entry is
> responsible, assuming you can access the AP at all.

Do you have idea if it is possible to write such check in kernel 
if address (aes@480c5000) is readable or not?

I have configured two testing N900 devices. One with signed 
bootloader which enable omap aes support and one device with 
signed bootloader which does not enable omap aes support.

So I can run any code/kernel patch and compare results/dumps 
between those two devices.

Just I do not know what to do, or what to test...

-- 
Pali Rohár
pali.rohar@gmail.com

["signature.asc" (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]