MIME-Version: 1.0
References: <20190222100613.2290-1-christopher.spencer@sea.co.uk>
 <20190222100613.2290-5-christopher.spencer@sea.co.uk> <VI1PR0402MB34851F1E7021F16B45F74E55987A0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
 <CAGUNXRTvXVU7vRicF=mR7xxCj=p+Sqj3aNnL2TezLZXhHFkvzA@mail.gmail.com>
 <VI1PR0402MB34857504705A898A59085B4B987B0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
 <CAGUNXRRcaiGAaKkUs2Tw_aZD4QKHtJMFLwkfu92pMu3jCBo5gw@mail.gmail.com>
In-Reply-To: <CAGUNXRRcaiGAaKkUs2Tw_aZD4QKHtJMFLwkfu92pMu3jCBo5gw@mail.gmail.com>
From:   Chris Spencer <spencercw@gmail.com>
Date:   Thu, 28 Feb 2019 11:33:44 +0000
Message-ID: <CAGUNXRTR3=xbj-scY=t4jqErcxQTsWHJM=sVESKZxNVHrLB_0g@mail.gmail.com>
Subject: Re: [RFC 4/4] crypto: caam - use job ring for RNG instantiation
 instead of DECO
To:     Horia Geanta <horia.geanta@nxp.com>
Cc:     Aymen Sghaier <aymen.sghaier@nxp.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        Chris Spencer <christopher.spencer@sea.co.uk>,
        dl-linux-imx <linux-imx@nxp.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Tue, 26 Feb 2019 at 16:24, Chris Spencer <spencercw@gmail.com> wrote:
> > > The original commit which added the run_descriptor_deco0 function [3]
> > > states "[...] and another function that performs the running of the
> > > said descriptor using the DECO debug mechanism." My best guess is that
> > > the DECO debug mechanism is no longer available so it has to go via
> > > the job ring.
> > >
> > This change is actually orthogonal to i.MX8 MQ support and is related to
> > SECO-based i.MX8 SoCs (QXP, QM) and/or OP-TEE support.
> >
> > Access to CAAM global registers (CCSR page 0) won't be allowed in cases when
> > Linux runs in Normal World.
> > From this perspective, it makes sense to eliminate accesses to these registers.
> > Some of the accesses are done for RNG initialization via the DECO debug
> > mechanism; to remove them, RNG is initialized via the Job Ring interface.
> > However, I still see some illegal accesses - for e.g. reading RDSTA register to
> > check which virtual RNGs ("state handles" in RM terms) are already initialized.
> >
> > It looks like cutting access to CAAM global registers must come with some
> > assumptions (since it implies some checks can no longer be performed, see RDSTA
> > above).
> > For e.g. in case OP-TEE is detected, we could assume that RNG was already
> > initialized. Similar for other cases like SECO f/w (i.MX8 QM and QXP).
> > If we make this assumption, it actually means RNG initialization is no longer
> > needed:
> >
> > if (!ctrlpriv->mc_en && rng_vid >= 4 && !normal_world) {
> >         ... // rng init as before - using DECO debug mechanism
> > }
>
> Thanks for the information. This is more problematic than I had
> anticipated. It sounds like these are the possible scenarios:
>
> 1. Linux is running in the normal world without OP-TEE/SECO; RNG must
> be initialised via the job ring. No way of checking whether the RNG is
> already initialised.
> 2. Linux is running in the normal world with OP-TEE/SECO; RNG
> initialisation is not required.
> 3. Linux is running in the secure world without OP-TEE/SECO; RNG can
> be initialised via DECO debug mechanism or job ring.
> 4. Linux is running in the secure world with OP-TEE/SECO; RNG
> initialisation is not required. This sounds like a very unlikely
> configuration.
>
> My build is currently sitting in scenario 1, which would explain why
> the RNG initialisation via DECO was failing. Clearly it can be made to
> work by running the initialisation via the job ring and assuming the
> RNG has not already been initialised, but I'm getting the impression
> that this may not be a sensible configuration.
>
> Is running Linux in the secure world a typical configuration? It's not
> a conscious choice I've made to run it in the normal world; that's
> just what the TF-A is doing. I suppose it's either that or start using
> OP-TEE so it can initialise the RNG.
>
> As far as driver support goes, are we only interested in scenarios 2
> and 3? I'm not really sure how we would detect which world we are
> running in, or whether OP-TEE has initialised the RNG.

Alright I think I'm making some progress on this. It seems that page 0
*is* available on the i.MX8M. I think it is the non-M variants with
the SECO which don't have this access.

What I have found is that if I set virt_en = 1 then the RNG is able to
initialise correctly via the DECO. The register values I am seeing
are:

comp_params = 01914201
scfgr = 00000001

So:
VIRT_EN_INCL = 1 & VIRT_EN_POR = 0 & SCFGR_VIRT_EN = 0

I don't have the i.MX8 security reference manual so there's only so
much analysis I can do, but it seems that virtualisation is enabled in
hardware without the registers reflecting that appropriately. If I
patch the TF-A to set SCFGR_VIRT_EN = 1 in the same place it sets
CAAM_JRxMID = 1 then everything seems to work, but I've got no idea if
that is an appropriate change to make.

Chris