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

[Julius Werner]

> That draft is the DEN0135 document [2].
> I realise that I haven’t made it sufficiently explicit in this thread that the DEN0135 document [2] is still at draft quality (see ALP maturity called out in the title page and footers).
> Please do not consider this a finished document 😊. We’ve been iterating on this pdf as we gather feedback from the open-source communities.
> It's becoming clear that we need to move this debate to a more suitable forum.
> That’s why we’re proposing, in this thread, to move the document to trustedfirmware.org.

Understood. FWIW, I totally support hosting this on TF.org, I think
that makes sense considering that it has good co-development
infrastructure that is open to everyone (e.g. Gerrit) already set up
and that it's easy to administer for you guys who are currently
organizing this. I don't really see Simon's concern regarding "captive
to one project" -- this whole spec is an attempt to cooperate better,
not work against each other, so there shouldn't need to be fights
about who "owns" it (just pick a place with good infrastructure and
let everyone access it there). If perhaps the real concern is rather
related to who controls future spec updates, tag assignments, etc.
then I think we should address those directly and define clear
processes that we can all feel comfortable with, rather than implying
that the final word on these is left to whoever controls the hosting
platform.

> The requirement originated in feedback from the u-boot community, please see [3].
> The argument for 16-byte alignment is that some data-structures have to be 16-byte aligned.
> We ought to meet that requirement if we ever want to carry those structures.

I still really think that this is wasting space to the point where it
defeats the purpose of this being a "lightweight" data handoff
structure. Consider that all of the bl_aux_params tags in TF-A (which
I described as one of the existing mechanisms for this kind of thing
in last year's thread) are 8 bytes or less, which means that for these
use cases the transfer list would have over 3 times as much overhead
as actual data. There seems to be some disconnect here since the
stated idea for this is to be a lightweight handoff mechanism to pass
individual pieces of information directly, yet all the initially
proposed tags are just for wrapping large existing hand off blobs that
bundle lot of information in their own structures (giving it a very
xkcd.com/927-like feel), and the spec design seems to be tuned toward
the latter use cases.

If individual tags have special alignment requirements, they could
just deal with that internally (by including another offset field in
the "data" part) without dragging every other tag in the structure
down with them. Alternatively, if you really want to keep this I think
an acceptable compromise could be to keep the 16-byte entry alignment
but reduce the transfer entry header size to 8 bytes, and then allow
tags that don't require 16 byte data alignment to immediately use the
following 8 bytes for data. That way, entries with 8 bytes or less of
data could fit both header and data into a single 16 byte block which
drastically cuts down on overhead for small data.

> > 2. The table entry header seems unnecessarily large. What's the point of
> > including a "header length" field when that field will always contain a 16?
>
> The "header length" enables the table entry header to be extended if we ever need that in the future.
> Changes to the TE header are backwards compatible.
> A consumer obtains the address of the data by adding the "header length" to the entry's base address.

I really don't see this as likely enough to be worth paying that big
upfront cost of making the whole structure so much less efficient to
start with. I think 8 bytes are already the most you'd reasonably want
to pay for header overhead, I find it highly improbable that we'd want
to introduce more fields later to make that even bigger. If there's
desire for optional large annotations (e.g. per-entry cryptographic
hashes) in the future, I'd rather suggest implementing that as
"companion entries" with special tags that are written right behind
the entry they refer to, rather than try squeezing it all into a
single header structure. If you want to leave some room for simple bit
flags, I would suggest masking out the high byte of the data length
field instead (i.e. splitting it into 3 and 1) -- it doesn't seem like
anyone would want to pass a data item larger than 32 MB in a firmware
information structure anyway.

> The TL header version is incremented when we do a new release of the document.
> At a new document release, we can introduce one or more new standard tags and also append fields to the TL header.

FWIW I would suggest decoupling the data structure version from the
document version and only increasing the data structure version when
the actual structure changes in a meaningful way. Documents may be
amended to improve clarity or add more detailed explanations that
don't always require parsers to actually act differently, so
increasing version numbers in the code for those cases would seem to
just unnecessarily confuse things.

> > 4. I don't think a strict definition of entry type ranges is a good idea,
> > particularly if "standard" and "OEM" are the only two options.
>
> As mentioned above, the standard tag range ought to have a low-barrier for new tags to be requested.
> The OEM range allows FW integrators to carry platform-specific entries that may not be generalizable.

Okay. This definitely needs to be specified in more detail and give
more guidance about where tags should be allocated for what case,
because my first impression from reading the doc was apparently quite
different than yours. I think the spec should strongly encourage
allocating a global tag whenever there might be the slightest
possibility that other platforms might want to use it later. For
example, maybe we can define the guideline that anything referred to
by any code checked into the upstream of any open source project
(U-Boot, TF-A, whatever) should always be a global tag. I guess a
small range of OEM tags makes sense for closed source downstream code
that isn't shared with anyone, but that should be the only use case
for that (so that open source projects can always freely collaborate
and adopt each others' standards without the risk of tag clashes).

> The feedback we received so far is: data should be included in the TL as that simplifies procedures, such as relocating the data, without having to worry
> about stale pointers.

I generally agree with that sentiment, but I also don't see including
a whole FDT or ACPI table in this structure as a normal case -- that's
more of a pathological edge case necessary to interface with
environments that use these other hand-off structures (because all
these are really just different ways to do the same thing, and there's
no real benefit from wrapping one in the other... it's just an
unfortunate necessity due to different boot stages expecting different
things). I really expect these to be mostly independent (and come with
their own placement requirements, which is a problem for direct
inclusion), I would expect at least some platforms to need the
flexibility of keeping them separate and therefore think it would be
better to standardize on that. But if other platforms really think
it's important to have these inline in the transfer list for their use
case, you could offer separate tags for both.