> What does that practically look like? Every time we have to re-walk we have to reverify the integrity of the metadata.

I mean, that is exactly what we're doing right now anyway (unless
something significantly changed in CBFS code since the last time I
checked). For every single CBFS file access we start at the root and
we walk the chain until we find the file we're trying to load (and all
of this are real SPI transfers, it's not cached anywhere). Hashing
times are generally insignificant compared to SPI access times IIRC
(especially since this should be a raw hash, not an RSA signature like
we use in current vboot). Validating the hash means we have to walk
the whole CBFS directory rather than stopping at the file when we find
it, but since we generally don't really pay attention for CBFS file
placement for performance right now that's presumably not a big deal
(would only double cost on average).

And there are certainly still ways to improve this with the right
caching, and ways to do that in a safe way even if verification is
involved, which we could explore if we wanted to. I'm just saying as a
baseline that the cost of CBFS walks seems to have never bothered us
in the past, so the comparable cost of reverifying metadata probably
shouldn't be a major criterion to reject the per-file approach.