Hi Raghu,

I do agree with you: case 2 and 3 are similar (wrongly formed DTB) and should lead to the same behavior.

A mandatory property miss or a hit with a structurally incorrect node means that the DTB doesn't follow the provided binding document. Such a DTB shouldn't be considered as valid and should trigger a build failure and/or a code panic.

With the current implementation, case 2 and 3 are similar. The property_getter() functions expect a specific format of the node. If a node is not found or structurally incorrect, the function will return an error code, which will lead to a panic().

regards,
Louis

From: TF-A <tf-a-bounces@lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 06 April 2020 19:51
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: Re: [TF-A] fconf: Validating config data
 
Thanks Louis. This new terminology helps. Let me spell this out again
just to make sure we're on the same page. The following are the cases:

1) Mandatory Property hit, nodes are structurally correct - Works normally.

2) Mandatory Property hit, nodes are structurally *incorrect* - Asserts
should catch structural issues during development because system
integrator expected to not make mistakes with number of nodes etc.

3) Mandatory Property miss - Panic(). Why is this case causing a panic,
but not case 2? You are allowing for some one to make the mistake of not
having a mandatory property, but assume that if a mandatory property is
present, it is always structurally sound. This is the part i have a
problem with. In my view case 2 and case 3 should panic and code should
not just assert on mandatory properties and must ALWAYS check for
structural soundness of an FDT property.

Similarly there are 3 cases for optional properties.

My question: Why does case 3 panic, but not case 2 ? It sounds like your
assumption is that case 2 cannot happen. If case 2 cannot happen, i
claim that case 3 cannot happen either.

Let me know what you think!

Thanks
Raghu

On 4/6/20 3:57 AM, Louis Mayencourt via TF-A wrote:
> Hi Raghu,
>
> Let me try to clarify/reword my idea:
>
> We complete the fconf documentation with a binding document, which
> defines the nodes that should be present in the config DTB to consider
> it as valid/well-formed. The document contains two kinds of node:
>
>   * mandatory (critical): the firmware can't proceed without this
>     information (example: load address, image UUID, ...). If this node
>     is not present in the DTS, the build fails and/or the code panic.
>
>   * optional (no-critical): the firmware can assume or assign a default
>     value and proceed (example: uart config, enable authentication flag,
>     ...). Such a property is used to influence the default behavior of
>     the firmware.
>
> />> This is non-deterministic failure./
> The miss of a mandatory (critical) node will always lead to a build
> failure / code panic.
> The miss of an optional (no-critical) node should not influence the
> default behavior of the firmware.
>
> />> Is it not confusing to make the assumption that a DTB is "well
> formed",i.e expect the build process/integrator to not mess up the
>>> structure or number of nodes but allow the same integrator to miss a critical property in the DTB?/
> A DTB with a missing mandatory (critical) property should not be
> considered well formed.
>
> />> If there is a missing critical property, is that not a badly formed
> DTB?/
> With the above definition, it is.
>
> />> And if so, why not check for badly formed DTB's uniformly in code
> and why only check for missing "critical" properties?/
> With the rewording of "critical" / "no-critical" to "mandatory" /
> "optional", I think the situation is clearer: A DTB with a missing
> "optional" node/property is is still considered well-formed.
>
> I hope I answered your questions and clarify the idea behind the design.
>
> regards,
> Louis
>
> ------------------------------------------------------------------------
> *From:* Raghu Krishnamurthy <raghu.ncstate@icloud.com>
> *Sent:* 05 April 2020 00:06
> *To:* Louis Mayencourt <Louis.Mayencourt@arm.com>
> *Subject:* Re: [TF-A] fconf: Validating config data
> Thanks Louis.
>   >>you can imagine a well-formed DTB which contain a
>   >>critical set of properties and can contain some optional properties.
>
> This makes things even more confusing. The assumption we are asking code
> to make is that the DTB is always "well formed", ie don't check for
> structural issues such as extra nodes etc, but we are still making the
> distinctions between critical and non-critical properties, that may or
> may not exist in the DTB, which may or may not cause a panic. This is
> non-deterministic failure.
> Is it not confusing to make the assumption that a DTB is "well
> formed",i.e expect the build process/integrator to not mess up the
> structure or number of nodes but allow the same integrator to miss a
> critical property in the DTB? If there is a missing critical property,
> is that not a badly formed DTB ? And if so, why not check for badly
> formed DTB's uniformly in code and why only check for missing "critical"
> properties?
>
> -Raghu
>
> On 4/3/20 3:16 AM, Louis Mayencourt wrote:
>> Hi Raghu,
>>
>> I do agree that we need something similar to a binding document for
>> fconf properties. (similar to
>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/components/spci-manifest-binding.rst).
>
>> At least for the common properties.
>>
>> The main idea behind the return code of the populator function was to
>> allow the code to handle no-critical property misses or to handle
>> critical failure by calling a platform hook.
>> With this in mind, you can imagine a well-formed DTB which contain a
>> critical set of properties and can contain some optional properties. The
>> return code and the populator "name" / "config" can be used to handle
>> this two cases.
>>
>> I tried to keep the design of fconf really simple, to leave room for
>> improvement according to feedbacks. Thanks for helping improving it!
>>
>> Regards,
>> Louis
>> ------------------------------------------------------------------------
>> *From:* TF-A <tf-a-bounces@lists.trustedfirmware.org> on behalf of Raghu
>> Krishnamurthy via TF-A <tf-a@lists.trustedfirmware.org>
>> *Sent:* 03 April 2020 10:15
>> *To:* tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
>> *Subject:* Re: [TF-A] fconf: Validating config data
>> A further point is that the fconf populators return an error code and
>> panics on error today. But if we are making the assumption that the
>> DTB's are well formed, do we really need to fail or even return an error
>> code?
>>
>> -Raghu
>>
>> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote:
>>> Hi All, (Sorry for the long email)
>>>
>>> The review
>>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845
>>> attempts to fix bounds check in the fconf populator code for the
>>> topology and SP's. During review, Sandrine thoughtfully pointed out that
>>> there were discussions around bounds check along the same lines in the
>>> review
>>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and
>>> it was deemed sufficient to have assertions in code and it was safe to
>>> make the assumption that the DTB is always well formed and contains
>>> valid values. I think this email mostly echoes Sandrine's concern from
>>> review 3492.
>>>
>>> While i agree with the assumptions, I am generally of the opinion that
>>> we should validate/range-check any data, even if it is signed. Being
>>> signed does not necessarily mean the data is well formed/valid. If there
>>> is a mistake in the build process and it is validly signed, it is
>>> possible that we silently corrupt state/data that could later be used to
>>> exploit firmware and/or make debugging hard. This is probably far
>>> fetched, but the cost of adding the check is trivial to avoid this
>>> possibility.
>>>
>>> I imagine the case where you have secure partitions signed by different
>>> entity other than the silicon provider(dual root-of-trust). A silicon
>>> provider provides a dev system for the SP provider to test and validate
>>> the SP's on silicon. The silicon has production firmware(and hence no
>>> assertions), but loads signed data from the SP provider which has some
>>> invalid values. There could be silent corruption without any indication
>>> whatsoever about what went wrong and it may be hard to debug if/when
>>> there are issues.
>>> Also, testing does not necessarily catch all invalid values since you
>>> will likely not get 100% coverage, given the number of config options
>>> available. Moreover, the code today, is not consistent in asserting on
>>> every property for valid values and the failure mode is not
>>> consistent/deterministic. It seems like every config option should have
>>> a list of valid values or a range of acceptable values that must be at a
>>> minimum asserted on.
>>> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT
>>> is likely to be turned off since it really does not provide any
>>> security, so assuming we always have signed data might not be valid.
>>>
>>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P
>>>
>>>
>>> Thanks
>>> Raghu
>> --
>> TF-A mailing list
>> TF-A@lists.trustedfirmware.org
>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy
>> the information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy
> the information in any medium. Thank you.
>
--
TF-A mailing list
TF-A@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.