From: Bryan O'Donoghue Subject: Re: [RESEND PATCH 0/6] Enable CAAM on i.MX7s fix TrustZone issues Date: Fri, 26 Jan 2018 01:06:00 +0000 Message-ID: <1c7a9b01-d12b-0887-27ed-dbd8c66910c9@nexus-software.ie> References: <1516805435-15034-1-git-send-email-pure.logic@nexus-software.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: Fabio Estevam , Peng Fan , "herbert@gondor.apana.org.au" , "davem@davemloft.net" , "lukas.auer@aisec.fraunhofer.de" , "rui.silva@linaro.org" , "ryan.harkin@linaro.org" To: =?UTF-8?Q?Horia_Geant=c4=83?= , Aymen Sghaier , "linux-crypto@vger.kernel.org" , "linux-kernel@vger.kernel.org" Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org 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