On Fri, May 16 2025, Simon Glass <s...@chromium.org> wrote: > Hi Rasmus, > > On Fri, 16 May 2025 at 14:54, Rasmus Villemoes <r...@prevas.dk> wrote: >> >> >> While not perfect, we can give a reasonable estimate of an upper bound >> on the necessary extra size by simply counting the number of hash and >> signature nodes in the FIT image. >> >> As indicated in the comments, one could probably make it even more >> precise, and if there would ever be signatures larger than 512 bytes, >> probably one would have to do that. But this works well enough in >> practice for now, and is in fact an improvement in the normal case: >> Currently, starting with size_inc of 0 is guaranteed to fail, so we >> always enter the loop at least twice, even when not doing any signing >> but merely filling hash values. >> > > I have no particular objection here if you really want to go this way, > but it seems to me that it would be better to have a way to determine > the size of signatures using a new (or existing?) API call. Then you > can make this deterministic and always correct.
Well, I'm not saying I won't revisit this at some point in the future and improve on the heuristics. However, as indicated, it's not just a matter of knowing the exact size of the signature data; one also has to account for the space used by the "hashed-nodes" property, which of course depends on the number of elements in the sign-images property, but also on the number of hash-* nodes in those "pointed-to" images. So it ends up being quite a lot of code to get it more exact. So yes, for now I would like to go this way, because it's a fix that works for my use case now and is easy to reason about, and should also be an improvement outside my use case in that it avoids at least one iteration, but possibly many. Rasmus
