-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optee-os: add optee rpmb support #326
Conversation
@@ -0,0 +1,460 @@ | |||
From cf20f0a4f77eddf47f278f3d20dc786793542ab4 Mon Sep 17 00:00:00 2001 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't test it yet just bring it up for discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't checked it but I notice this patch already acked by Linaro, so I guess this is already upstreamed or under upstreaming... So I believe somebody else had already tested it...
I think this patch is the prerequisite for the following SCI api patch so it must be picked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, if we can pick the patches via upstream, that would be better. But the question is also if there is already a release with the patch included...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am ok with a OPTee version bump as long as it does not generate clearing delta.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More important would be a careful check if security fixes need to be picked up - we are starting to put OP-TEE on the critical path now for real.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. We have CERT report to refer to, maybe that could be helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, if we can pick the patches via upstream, that would be better. But the question is also if there is already a release with the patch included...
there is no release, it's not under any tags, it's just directly from master which could be to dangerous to bump into that state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't checked it but I notice this patch already acked by Linaro, so I guess this is already upstreamed or under upstreaming... So I believe somebody else had already tested it...
I think this patch is the prerequisite for the following SCI api patch so it must be picked.
Yes, TI and me both did testing but not for 3.16.0, I'll test it out to check if all works from upstream.
|
||
require optee-os-iot2050_3.16.0.inc | ||
|
||
OPTEE_EXTRA_BUILDARGS += " CFG_RPMB_WRITE_KEY=y" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's control that via an OVERRIDE
, something like OPTEE_EXTRA_BUILDARGS_append_rpmb-setup = '...'
. Then you can fold both recipes together again. The override would be set by a kas option file, similar to the secure boot enabling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I'll check how it will goes with OVERRIDE.
We also need that kas option file to enable the special firmware build. And that setup should exclude signing the firmware, ie. detect and reject secure boot mode. With that safety measure, I think we could offer to build the special firmware also via kconfig. That would additionally provide the change to explain the usage and constraints in the help entry. |
kas-iot2050-boot-pg1-optee-rpmbw.yml |
Do we need pg1/2 differentiation for that? Officially supported will be pg2 only anyway, but we can leave that door technically open. Otherwise maybe |
e57bf82
to
e8b3747
Compare
What is now the actual testing status of these OP-TEE patches in the backported environment (3.16.0, rather than master)? Can we trust that? Or should we move at least to 3.17.0 (upstream merged them not that many commits after the release)? |
3.16.0 works fine with backported patches. 3.17.0 and 3.17.0-rc1 don't have these patches, probably in new rc or .18 it will be available. |
0efef04
to
c90f3ec
Compare
Last version of commits is not tested with 3.18.0, will do it on the current week. |
Testing on PG2, below error print could be confusing.
This happens during Line 64 of /* Try to claim the SA2UL firewall for ourselves */
ret = ti_sci_change_fwl_owner(fwl_id, sa2ul_region, owner_index,
&owner_privid, &owner_permission_bits);
if (ret) {
/*
* This is not fatal, it just means we are on an HS device
* where the DMSC already owns the SA2UL. On GP we need
* to do additional setup for access permissions below.
*/
DMSG("Could not change SA2UL firewall owner");
} So it is expected on HS device. However, it is still confusing if I am a end user. Already reported to upstream, see: OP-TEE/optee_os#5552 & https://github.com/OP-TEE/optee_os/pull/5328/files#r979529747 |
Seems |
I think we should have some wikis regarding how to program the RPMB key, just as what we've done for secure boot otp key programming. |
This patch provides rpmb support for IOT2050 on am65 which includes: * TISCI protocol support * DKEK retrieval * DDR setup for DYNSHM * compile option changes for optee Signed-off-by: Ivan Mikhaylov <[email protected]>
Signed-off-by: Ivan Mikhaylov <[email protected]>
This patch provides do_patch_prepend for OPTEE recipe which needed for prevention of usage rpmb-setup and secureboot because rpmb-setup shouldn't be used on production systems. Signed-off-by: Ivan Mikhaylov <[email protected]>
c90f3ec
to
69fc6d3
Compare
Test passed on PG2 device. |
This patch provides rpmb support for IOT2050 on am65 which includes:
Signed-off-by: Ivan Mikhaylov [email protected]