On 25-03-12, Sascha Hauer wrote:
> On Tue, Mar 11, 2025 at 02:42:07PM +0100, Marco Felsch wrote:
> > > struct fip_state *fip_image_open(const char *filename, size_t offset)
> > > {
> > > @@ -470,11 +466,13 @@ struct fip_state *fip_image_open(const char *filename, size_t offset)
> > > int ret;
> > > int fd;
> > > struct fip_state *fip_state;
> > > - LIST_HEAD(entries);
> > > size_t fip_headers_size, total = 0;
> > > - struct fip_image_desc *desc;
> > > off_t pos;
> > > int n_entries = 0;
> > > + struct fip_toc_entry toc_entries[16];
> > ^
> > Why did you used 16?
>
> Okay okay, I allocated the entries dynamically now to support an
> arbitrary number of toc entries.
Nice, thanks :)
>
> Sascha
>
> -------------------------------8<------------------------------
>
> From 87bc7468e698e3404345ee601885ec186de7f4fa Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
> Date: Tue, 11 Mar 2025 13:25:18 +0100
> Subject: [PATCH] fip: rework fip_image_open()
>
> fip_image_open() used to do all the parsing into a struct fip_state
> itself. Instead, only load the FIP image into a buffer and call
> fip_do_parse_buf() with this buffer. This has the advantage that we
> have all parsing of the FIP image in a single place. Also this helps
> with a followup patch which calculates a sha256 over a FIP image
> which can easily done when we have the whole FIP image in a contiguous
> buffer.
>
> Link: https://lore.kernel.org/r/20250311-am625-secure-v2-5-3cbbfa092346@xxxxxxxxxxxxxx
> Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
Reviewed-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
if not already to late.
