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

[Simon Glass]

Hi,

On Wed, 30 Nov 2022 at 16:48, Julius Werner <jwerner at chromium.org> wrote:
>
> 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.

I don't know where that idea came from and I thought I read the same
threads. I think FDT is the best data structure in general, because it
is self-describing, can be understood just by dumping it and we can
use schema tools to validate things, and many other reasons. Overall,
as an industry, I believe it is best to get away from ad-hoc binary
structures.

So all projects which need to send or receive complex data should use FDT.

For replacing bl_aux_params, I think FDT makes sense in general, but
there may be situations where a few TEs are useful though.

The point of the transfer list is to deal with cases where we don't
have enough memory / CPU power to use libfdt. This happens very early
in boot, and in that case it is helpful to pass small data structures
containing useful information.

Actually even just grouping data structures (FDT, ACPI things) in a TL
is useful, since we have a unified way to find them all.

I replied on the github PR also.

>
> > 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.)

I initially thought that was fine, but then I realised that this loses
the 16-byte alignment of the entries.

Regards,
SImon