Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RESEND PATCH 0/6] Enable CAAM on i.MX7s fix TrustZone issues
To:     =?UTF-8?Q?Horia_Geant=c4=83?= <horia.geanta@nxp.com>,
        Aymen Sghaier <aymen.sghaier@nxp.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc:     Fabio Estevam <fabio.estevam@nxp.com>, Peng Fan <peng.fan@nxp.com>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "lukas.auer@aisec.fraunhofer.de" <lukas.auer@aisec.fraunhofer.de>,
        "rui.silva@linaro.org" <rui.silva@linaro.org>,
        "ryan.harkin@linaro.org" <ryan.harkin@linaro.org>
References: <1516805435-15034-1-git-send-email-pure.logic@nexus-software.ie>
 <VI1PR0402MB3342F22397EEF7CF009BA4C598E10@VI1PR0402MB3342.eurprd04.prod.outlook.com>
From:   Bryan O'Donoghue <pure.logic@nexus-software.ie>
Message-ID: <1c7a9b01-d12b-0887-27ed-dbd8c66910c9@nexus-software.ie>
Date:   Fri, 26 Jan 2018 01:06:00 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <VI1PR0402MB3342F22397EEF7CF009BA4C598E10@VI1PR0402MB3342.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=iso-8859-2; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 25/01/18 17:50, Horia Geant? wrote:
> If the first ("global") caam register page is not accessible, RNG init is not
> the only problem. For e.g. device endianness detection won't work.

Hi Horia,

Yes I had that thought that there were other gotchas lurking once the 
CAAM was in a more restricted mode.


> A complete list could be generated by auditing all places where this page is r/w.

quote:

"The CAAM address space is divided into 16 4 KB pages to
match the access granularity of the MMU. Registers that are
intended to be accessed by a specific processor or process are
grouped into one of these 16 pages so that access to these
registers can be restricted via CAAM's own MID-based access
control mechanism, or via the CPU's MMU. For instance, the
general configuration and status registers are located within
page 0 and are intended to be accessed only by privileged
software. The registers that control each job ring are located in
a separate address block so that access to each job ring can be
restricted to a particular process. Some registers, such as the
version ID registers, are intended to be shared among processes.
Rather than require each CAAM driver process to have two
MMU page entries, one page for its private registers and one
for the shared registers, CAAM "aliases" these shared registers
into the upper section of each of the 16 address blocks. Reading
any one of the address aliases for the same register returns the
same information. Some of these aliased registers are writable,
so access to these registers may require that software implement
a concurrency control construct, as would be the case with any
register that is read/write accessible by multiple processes."

Not all of the first page is restricted - just some of it, I haven't 
found a detailed explanation of which parts are restricted and which 
parts are not.

Referring to "Security Reference Manual for i.MX 7Dual and 7Solo 
Applications Processors, Rev. 0, 03/2017" section 8.10.1 you'll see 
there are alias registers for example offset 0x204 DMA Control (DMAC) 
which is r/w.

The above is the best description of the behavior I've found - I assume 
there's some internal documentation (or RTL test benches) you guys can 
refer to in NXP. I don't know if that's something you or Peng of Fabio 
can follow up on internally.

> IMHO the correct direction for solving such cases (i.e. Linux kernel is provided
> only with access to a few job rings) is to split the driver in two independent
> ones - controller driver and job ring driver - and have corresponding DT nodes
> for them. Controller DT node and one or more of the job ring DT nodes would be
> deleted by the boot loader / trusted firmware if needed.
> Of course, the job ring DT node might need additional properties for the driver
> to work.

Well, I certainly take your point that there are probably other things 
that are broken which we just haven't stumbled over yet. RNG broke for 
us, we fixed it but, for example we haven't tried using RSA acceleration 
so that might necessitate that type of change - or indeed what happens 
if you make a call into the HAB (which will use the CAAM for crypto 
acceleration) when the TZ restrictions are in-place.

Does HAB/ROM even run @ EL3 ? I expect so but, I don't know.

This series in V2 will just be about

1. Enabling for i.MX7
2. Fixing a few bugs we've found along the way.

It does look like we can solve the RNG permissions problem exclusively 
in u-boot... but I will take some time to look at endianess and any 
other low-hanging fruit you can suggest for that V2 series.

---
bod