Date:   Mon, 15 Nov 2021 12:40:03 +0100
From:   Michael Walle <michael@...le.cc>
To:     ZHIZHIKIN Andrey <andrey.zhizhikin@...ca-geosystems.com>
Cc:     horia.geanta@....com, pankaj.gupta@....com,
        herbert@...dor.apana.org.au, davem@...emloft.net,
        iuliana.prodan@....com, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: caam - check jr permissions before probing

>> > As for probing of the JR node, then I believe it is rather the
>> > opposite:
>> > deciding whether the JR is available during probing provides an
>> > opportunity to bind the device later on when it would be released from
>> > S to NS world (provided that this would ever occur). However, keeping
>> > in mind that there is no HW mechanism to indicate that the JR appears
>> > in NS world after the boot and the user transfer should be done
>> > manually by some other SW entity - later bind can also be performed
>> > there.
>> 
>> Sure, but it will also be the other way around, no? Like S world can 
>> "steal" the JR
>> from NS world. And thats what I'm worried about.
> 
> This is actually the key point, and I neglected this a bit completely
> unintentionally.
> 
> If the software entity running in S World would like to reclaim the JR
> from Kernel,
> then it can do so at any given point of time. This for sure should be
> carefully crafted
> according to "Ring user (re-)assignment procedure" described in SRM,
> but what this
> would mean in practice for the Kernel is: any crypto operation running
> inside that JR
> would either complete or be abrupted. Once S World entity would reclaim 
> the JR,
> the NS Word software entity should unbind the JR and stop using it
> while submitting
> operations for CAAM Algos.
> 
> There is a conceptual problem here with this scenario, namely: S World
> should notify
> the NS World that a particular resource (JR in our case) is reserved
> and should not be
> used at all. AFAIK this mechanism is not present, and until it is not
> there - there
> would be no chance to realize that the JR is gone.
> 
> Please note, that this patch (and consecutive V2 series) are not
> addressing above
> problem and was never intended to. The scenario you're talking about
> is a part of
> a bigger task, which is separate from what this patch covers.

I didn't imply that it should, I just questioning wether we should
blindly trust the DT (and that would mean someone, i.e. u-boot
have to dynamically patch it) or we we shouldn't trust it and the
kernel should figure it out on its own (this patch).

Do you know if there are any drivers in linux doing the latter?


> Just to make it clear: this patch (and consecutive V2 series) tried to
> address the
> functionality to dynamically identify which JR is not available for NS
> World at the
> Kernel boot and mark them accordingly. This allows that different
> derivatives that
> have CAAM HW IP to have any JR reserved, and would not require no 
> changes in
> DTB to have a node disabled.
> 
> There are several key components running in S World before Kernel 
> (BootROM, SPL,
> ATF, OP-TEE) and they all can have JR reserved. If any of those
> software instances
> reserve the JR - then currently it should disable it in the DTB as
> well. This patch allows
> them not to do so, and moving the identification logic into the Kernel
> to dynamically
> figure out which resources are there to use.

And this is exactly what I'm worried about (or lets say unsure).
Whether we shouldn't trust the DT.

>> > The only difference to the current proposed solution would be to
>> > examine the CAAM control register instead of the flag from JR while
>> > probing, and this is what I'm currently testing on my end.
>> >
>> >>
>> >> So maybe u-boot (or TF-A) should mark that node as disabled after
>> >> all.
>> >
>> > If the U-Boot implementation would come up with similar dynamic
>> > recognition - then it would not be necessary to disable the node there
>> > as well.
>> >
>> > This would also ensure that if in later derivatives or ATF code
>> > updates another JR would be reserved as well - there would be no need
>> > to change and align DTB to it, as it would be dynamically recognized.
>> 
>> To be clear, I don't talk about dynamic behavior here. Just try to 
>> determine
>> where the JR should be disabled/removed from the DT. And I'm assuming 
>> a static
>> partition of the JRs between S and NS world.
> 
> As I've written above, I believe it would be hard to rely on static 
> partitioning
> between S and NS Worlds, as we have several S World agents in the game
> before Kernel starts. They either should have a clean contract to 
> establish this
> partitioning, or Kernel should be able to see which of those JRs are
> not available.
> This patch addresses the later since we do not have any rules regarding 
> the
> partitioning contract.

But isn't the contract the device tree?

>> To recap, NXP suggested to disabled it in the SoC dtsi in u-boot. This 
>> depends on
>> whether the BootROM actually assignes it to S worlds and there is no 
>> way for u-
>> boot to regain access (assuming that u-boot or u-boot SPL will be 
>> started in EL3).
>> If it is not possible to reassign it to NS world, then the JR should 
>> be disabled in
>> linux and u-boot DTs. If there is a chance to regain control and that 
>> there might
>> be no TF-A at all, then statically disable the JR in u-boot is wrong. 
>> Instead it should
>> be determined at runtime (again just static partitioning, no dynamic
>> reassignment).
> 
> Just to add: this proposal was done for i.MX8M Mini SoC only, which
> does not cover
> all other derivatives implementing CAAM.
> 
> I assume that if we go with DTB approach - all other derivatives
> should be revised
> and reserve nodes appropriate.

Yes, and I disagree how this is implemented in u-boot right now (or is
proposed) because its yet again the simple and fast solution. I still
think this should be done at runtime and the node should be disabled if
it looks like its not available. that is, it should do the same as you
are doing here. If there is some software in S world taking over the
JR sometime later, then the code in u-boot has to be revised (or the
device tree for this particular board has to be adapted).

>> I had a fixup at runtime of the DT (both the active DT in u-boot as 
>> well as the DT
>> passed from u-boot to linux) in mind. Check the TZ_OWN bit and 
>> remove/disable
>> the JR.
>> 
>> There is also an ongoing discussion where and how the DT will be 
>> passed to u-
>> boot and linux. So I might be the case that TF-A will allocate one JR 
>> to itself and
>> just pass u-boot the DT where that JR is disabled or removed. Which 
>> might also fit
>> the "fixup" in u-boot.
> 
> Yes, but in this case - all derivatives should have this done, right?

with derivatives you mean SoCs implementing CAAM? I thought of something
along the following:

ofnode_foreach_compatible_node(node, "fsl,sec-v4.0-job-ring") {
     if (caam_jr_is_unavailable())
         ofnode_set_enabled(node, false);
}

in the common dt_fixup for the SoC. So yes, this should be called for
all the SoCs which could have a CAAM. And it should also probably be
done for the control DT in u-boot.

> I'm not sure how
> this can be enforced, and also not sure how to keep this up in the 
> future...

I can't follow you here.

>> >> If the BootROM is actually already assigning this to secure world
>> >> (and setting the lock bit LDID). Then it can also be removed from the
>> >> linux dtsi, because there is no way it can be assigned to linux
>> >> anyways.
>> >
>> > As I've indicated above: the LDID bit is not set on this JR.
>> 
>> Ok, then u-boot should be able to reset the JR to its defaults if its 
>> started in EL3
>> (and there is no TF-A at all), right?
> 
> It can, if the CAAM driver finally lands in U-Boot and this 
> functionality is
> implemented in that driver. So far, both of those is not covered...
> 
> What I've just seen in V5 patch series for CAAM support in U-Boot [1],
> there is a dynamic reservation provisioned in SPL for any arbitrary JR 
> number.
> Therefore, I believe this patch makes total sense to isolate Kernel and 
> verify
> which JR is available at boot.

I still have to look at v5. but the one mail I got didn't look very
promising, as it says "we go with the "-u-boot.dtsi" approach
and just one jobring statically.

-michael

Powered by blists - more mailing lists