[TF-A] [RFC] Proposed location to host the firmware handoff specification.

[Julius Werner]

Okay, FWIW I created a pull request with my suggestions here:
https://github.com/FirmwareHandoff/firmware_handoff/pull/4

That should make it easier to discuss specific details, hopefully. As
I was looking at the header size and format more closely I noticed
that the checksum calculation and some details about what the size
fields mean seems underspecified right now, so I suggested a change
for that as well. Let me know what you think.

> One way to enforce that is for firmware components to refuse to accept
> a transfer list with unknown tags, assuming that all firmware is built
> from source at the same time. It might be a pain, but I suspect it
> could help avoid security problems, where bad actors use the structure
> to pass code to a firmware blob, etc.

I don't think that's feasible, particularly if tag IDs are not
allocated in order (which I think is useful so that we can try to
group similar tags by vendor, e.g. if say MediaTek wanted to add some
tags they could just find some nice round number in the tag space, say
0x200, and then start allocating 0x201, 0x202, 0x203, etc. while the
next vendor can do their own thing at 0x300 instead). It also creates
automatic incompatibilities if you put newer and older components in
the same image, which I think is something we explicitly don't want. I
think the right policy to encourage compatibility is that unknown tags
just get ignored.

> I have to disagree here. The context is gone in this email, so I
> cannot reply to the comments there. But I think it was talking about
> using the transfer list for very tiny structures, just a few words.
> That is not the intent. Firstly we should really have TF-A use the
> device tree (embedded in the transfer list) instead of replicating
> bl_params in this structure. Secondly, we should group things into a C
> structure that is at least 16-32 bytes long.

Uhh... okay, sorry, but then you're going against everything that was
discussed in this thread and in the previous discussions last year.
The whole idea of making this a tagged list came from the argument
that other structures (like FDT) are unnecessarily bulky and complex
for some of the intended use cases (like replacing TF-A
bl_aux_params). I mean, what's the point of even having a transfer
list if all it does is wrap an FDT? You could just use the FDT
directly! I think all the 4 tags that are currently specified in that
document are pathological edge cases that may be necessary for legacy
applications but represent the opposite of how this structure *should*
be used in the ideal case. We don't need just more wrappers for the
stuff that we already have, that doesn't promote interoperability in
any way. If project A only wants to use HOBs but not FDT, and project
B only wants to use FDT but not HOBs, then creating a transfer list
structure that can wrap both an FDT and a HOB in a TE is pointless and
not going to fix anything (project A will still not be able to parse
the FDT-wrapping TE, and project B will still not be able to parse the
HOB-wrapping TE). The only way this whole exercise can actually be
useful and improve anything is if we can use it to eventually (slowly)
get away from both HOBs and FDTs towards a point where all data is
encoded in TEs directly, without any extra layers.

> So I don't see a need for a smaller header. The 16-byte alignment
> works well with ACPI tables and we should not be using this structure
> for tiny things where the 8-byte overhead is significant.

FWIW, the compromise proposal now preserves the 16-byte TE alignment.
(8 byte header, then small entries can use the next 8 bytes for data
and the whole TE is only 16 bytes with only up to 7 bytes of forced
padding. Once you need more than 8 bytes of data it gets a bit more
ugly but at that point I guess you're not really a super small entry
anymore.)