quoted

quoted

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.

quoted

quoted

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.

quoted

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?

quoted

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).

quoted

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.

quoted

quoted

quoted

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