On 22/01/2020 17:44, Scott Branden wrote:
Hi Soby,
Comments inline. I will try and push a revert of the patch today.
On 2020-01-22 5:52 a.m., Soby Mathew wrote:
On 22/01/2020 12:29, Scott Branden via TF-A wrote:
Please revert the removal of RSA PKCS#1 v1.5 support from cert_tool:
https://github.com/ARM-software/arm-trusted-firmware/commit/6a415a508ea6acec...
We have products shipping with such support. I think this problem came up before when somebody tried removing such support. They still need to run with the latest yocto codebase.
Regards, >>> Scott
Hi Scott, It is untenable for us as maintainers to keep supporting deprecated features in the tree.
I think you're exaggerating the claim quite a bit here. The feature is not broken and is simply an option in cert_tool. And, as an open source project, ATF support does not fall completely on maintainers. We're will to keep PKCS#1.5 functioning in cert_tool. Please don't purposely break it. Keeping compatibility is a requirement in this case.
Hi Scott In this particular case it may be a revert of a patch, but I was generally referring to the case removing deprecated features in the codebase.
The removal in this case was done particularly to fix a bug in cert_tool as indicated in the commit message. It was easier to remove the code for a deprecated feature which fixed the bug.
In any case, wrt to compatibility, it is difficult for us double guess breakages for downstream platforms whereas we do our best effort to maintain compatibility for upstream platforms.
It is needed as BL1 is in ROM. We have no option other than to use PKCS#1.5 on SOCs that have already been designed.
We need to be able to move the codebase forward.
Code base can and has moved forward and can continue to do so. Removing RKCS#1 v1.5 doesn't prevent that in any way. This is just a flag option in the cert_tool utility. If you need to radically change cert_tool then create a new tool such as cert_tool2 and leave existing cert_tool as is.
As the commit message says, the RSA PKCS#1.5 support was removed from BL1/BL2 images before this patch, and it no longer made sense to keep the support for just the cert_tool.
BL1 is in our ROM. So it makes complete sense to keep support in cert_tool. We have a common codebase for all our SOCs and pickup new ATF bug fixes and features.
Unfortunately this is a not a simple revert of a patch as I mentioned above. Also we have to modify cert_tool part of upcoming features (see eg: https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/3250/) and it is not possible to keep removed feature support in the tool forever.
From your description, it seems a downstream fix for this earlier SoC is easier to maintain than a upstream revert. (eg: keeping single code base but have custom build variations for a earlier version of the SoC).
Again, I would like to re-iterate, if your platform were upstream, more could been done to help your case which will not limit bug fix and enhancement of the main cert-tool (maybe keep a platform variant of the tool or something).
Best Regards Soby Mathew
Seems that you are not using the latest TF-A code for your platform (since PKCS#1.5 is not supported), it does not make sense to pull the latest master just for the tool. So my suggestion would be pin your yocto scripts to a TF-A release that had the support for PKCS#1.5.
Not possible to pin to previous versions as we have a common codebase for all our SOCs.
Best Regards Soby Mathew
Regards, Scott