This looks great! Thanks for putting this together.
Thanks -Raghu
On 6/15/20 12:27 PM, Madhukar Pappireddy wrote:
Hi Raghu,
We had a discussion internally about handling the mandatory and optional properties in fconf and we believe we can use the following approach. Please let us know if it is acceptable to you.
As agreed over the mailing list, we treat the scenarios of a missing/incorrect mandatory property or a structurally bad dtb as an integration error and must lead to panic in runtime. It is the responsibility of the developer providing the populate callback to detect and return an error code in such scenarios. It will be treated as an unrecoverable error and further escalated to panic() by the fconf framework itself. An incorrect or missing optional property in a dtb should lead to a warning message and the boot loader should continue after assigning a default value to the specific property.
Further, every property accessed by a populate callback should be clearly defined as either mandatory or optional in a fconf based binding document such as the one shown here [1]. This must be enforced in spirit as part of the code review process. We believe the callbacks can be categorized into two: Generic vs platform-specific. Generic callbacks are the ones that are required to support a standard component supported by platforms running TF-A such as TBBR, SDEI, IO Policy, GICv3, etc. Platform-specific callbacks are provided by platform developers to work with non-standard components such as a Proprietary Hardware IP.
The binding document for generic populate callbacks should be provided by the TF-A project. The generic binding will become a contract for the platforms to implement the support for integrating standard components and hence, will be platform agnostic. Correspondingly, it is the responsibility of the platform developer to provide the binding for platform-specific populate callbacks.
Any thoughts?
[1] https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_pr...
Thanks, Madhukar
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Manish Badarkhe via TF-A Sent: Wednesday, May 20, 2020 6:00 AM To: Raghu K raghu.ncstate@icloud.com; Sandrine Bailleux Sandrine.Bailleux@arm.com; tf-a@lists.trustedfirmware.org; Louis Mayencourt Louis.Mayencourt@arm.com Cc: nd nd@arm.com Subject: Re: [TF-A] fconf: Validating config data
Hi Raghu
We have plan to work on this and come up with some design which handles mandatory/critical properties.
On 13/05/2020, 22:18, "TF-A on behalf of Raghu K via TF-A" <tf-a-bounces@lists.trustedfirmware.org on behalf of tf-a@lists.trustedfirmware.org> wrote:
Hi All, Since the 2.3 release is done, can we revisit this topic? I think we left this with finalizing on how to handle bad/incorrect DTB's. Sandrine's latest proposal below: "A bad DTB seems more like an integration error than a programming error to me, and thus should be handled with runtime checks according to the current guidelines. Incorrect values for mandatory properties should probably be treated as unrecoverable errors (causing a panic) and incorrect/missing optional properties as recoverable errors (issuing a warning message)." I agree with this proposal and think we should follow this. This addresses my original concern of handling errors consistently and being safe by verifying mandatory/critical properties at run-time. Thoughts ? Thanks Raghu On 4/13/20 10:27 AM, Raghu Krishnamurthy wrote: > Thanks Sandrine. Revisiting after v2.3 is sounds fine. > > -Raghu > > On 4/10/20 2:25 AM, Sandrine Bailleux wrote: >> Hi Raghu, >> >> On 4/8/20 12:50 AM, Raghu Krishnamurthy wrote: >>> Thanks Sandrine, Louis, >>> >>> Agree with both of you. I'm fine with using asserts or panics, as >>> long as we uniformly use it. The change i sent out(review 3845) was >>> because i noticed inconsistency in handling errors. If we do use >>> asserts, all code that checks for mandatory properties, should be >>> changed to assert as opposed to return error code. For optional >>> properties, we can continue to return an error code or print >>> warnings etc. >> >> Yes, I too think consistency is key here. As you said, we need to >> settle on the expected behaviour and enforce it uniformly across the >> fconf code. Let's revisit this code after the v2.3 release. >> >>> I would like to point out that using asserts here is different from >>> what is documented in the coding guidelines. The guidelines >>> explicitly spells out using asserts for "programming errors". >>> Now, is having a bad DTB considered a programming error? ;) The DTB >>> is platform data as opposed to code. The guidelines might need to be >>> updated based on the conclusion here. >> >> Now that you point it out, and after taking a closer look at [1], I >> think I was wrong. A bad DTB seems more like an integration error >> than a programming error to me, and thus should be handled with >> runtime checks according to the current guidelines. Incorrect values >> for mandatory properties should probably be treated as unrecoverable >> errors (causing a panic) and incorrect/missing optional properties as >> recoverable errors (issuing a warning message). >> >> [1] >> https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines.html#error-handling-and-robustness >> >> >>> Also note the couple of scenarios i mentioned in an earlier email. >>> Platforms like RPI4 don't generally enable TBBR and the DTB image >>> could get corrupt or be modified on purpose. On a release build, >>> this could cause silent corruption. Panic() would avoid this. >>> >>> In any case, it would be good to settle on the expected behavior for >>> each of these abnormal cases. I don't have a strong preference for >>> asserts or panics here, since each has its pros and cons as both of >>> you called out. >>> >>> Thanks >>> Raghu > -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a