Raghu as you are originator for this ask; can you state more about the requirements as to the why we'd really need to do so?

Is this really the a case that the image built for one platform has to scale to other platforms?

I'm under the impression that adding this information to the manifest requires more code in the manifest parser.
As a bit of a trade off, having this information statically defined makes sure there is no attempt to inject wrong values into the manifest dtb (admittedly the dtb would be signed though).
Adding more code in the parser looks to be increasing the attack surface.

Another remark from Usama is that a lot of early boot debug messages might be lost prior to reaching the parser, if the base address for the uart can only be figured out from the manifest.

Hi Olivier,

Appreciate you opening up the ticket.

can you state more about the requirements as to the why we'd really need to do so?

The problem is well described in this: https://lists.trustedfirmware.org/pipermail/tf-a/2021-March/001016.html. In summary, On highly configurable, non-vertically integrated systems(anything that is not a phone or edge device that comes from one vendor and is expected to be standards based), almost nothing is static. Even things like address maps of the system can change based on the number of sockets in a system, the number of DIMM's populated, number of PCIE devices populated etc and everything is discovered. A 2 socket system may want to use a different UART than a 4 socket system and the address of the SMMU's may be different on a 2 socket vs 4 socket system. For each of these different configurations, they are the exact same platform but different configurations since hardware is populated differently and it is not feasible for a SiP to provide different firmware packages for different configurations with different DTB's for the same platform. This has been the case in PC's and server systems for a while, which are not vertically integrated like typical embedded devices.

Adding more code in the parser looks to be increasing the attack surface.

We are not adding new parser code, we are adding new fields but using the same parser code. We are only adding code to parse the new field by extending the manifest. I dont view this as increase in attack surface because we are calling the same code but for different/new fields. If we wanted better security, i would say removing DTB and moving to a simpler alternative like blob list, hob list or even the bl_aux_params as has been suggested in the linked mailing list topic, are better options.

Another remark from Usama is that a lot of early boot debug messages might be lost prior to reaching the parser,

Alright, agreed. Then perhaps the solution is to make this platform specific call get an address at run time, similar to what we do for getting the fdt address, or using the FF-A specs boot protocol to get this information. There are other ways to solve this problem: For example we can log early messages to a buffer and flush once we have a console address. I recognize this has disadvantages of this approach to debugging early boot code but there are ways around this as well(use a debugger, hard code address until you debug and get the code stable etc). The other option is we move the manifest parsing earlier and again this has a tradeoff potentially with performance since the MMU might not be on but again, there are ways around this too.
The point is, Linux/Windows or any complex OS is able to discover these aspects from DT/ACPI etc without it being compiled for a particular SiP and function just fine so this is not an insurmountable issue.
Moreover, Hafnium entirely relies on the ARM architecture and there should be nothing specific to an SoC in the code. And anything SoC specific, such as the address map should be provided as data, like it is done for kernels. There is no real reason to treat hafnium like TF-A even though it is technically firmware in the secure world, but again, in the server market, this may come from a different party that is not the SiP and when the system is not vertically integrated.

Thanks
Raghu

The point is that this is not an insurmountable problem because Linux, Windows, or any other complicated OS can find these elements from DT/ACPI, geometry dash world, etc. without needing to be developed for a specific SiP, and they can function perfectly.