Firmware volume creation/replacement

[JulienVdG]

The linuxboot perl implementation has a create-fv for that, I'm not sure it's necessary here, all depends on how utk can handle the firmware volumes.

I think the insert visitor should be enough to fill existing volumes with extra files.

But there is nothing currently to add a fv.
The use case is for existing uefi platform where changing the flash layout is not possible but the flash includes some empty area. Creating a fv in each of those area will allow us to store extra data.

utk already find the empty area and creates BIOSPadding but there does not seam to be a way to touch them currently.

[JulienVdG]

@rjoleary We did talk a little about this during osf hackathon. I remember the idea of partition editing...
Have you given more thought to it ? Do you have some suggestion for the implementation ?

[GanShun]

How much customization do you want to allow for FV creation? One (terrible and tedious) way I suspect you can do it right now is to extract to an entirely new directory, add a new FV in and modify the json, then reassemble the image. However we can do better.

1. One simple way is to just add a visitor that inserts an FV into an empty region given a starting offset, and checks if there are other firmware volumes in that spot. The problem is that it's not clear to the user what offsets are safe and what aren't. We could add something that dumps the top level layout so we can see free space clearly. I assume you're trying to work with an Intel image. Is the free space you're talking about part of the bios region? are you only trying to replace the BIOSPadding? or are you trying to use other empty areas such as the ME region or PD region?

2. What happens if the user wants to insert a nested FV? I don't currently see use cases for that, so we could just not allow it or ignore it. (Note that a user could still insert nested FVs today if they wrap the FV in a File and insert that)

3. More generally I want to also be able to extend existing FVs into empty space after them. I'm not sure what the best way to do this would be. One way is to dump a high level summary that only has detail down to the top level FVs. Kind of like the way ifdtool dumps a small summary with offsets into a file, and you can modify that and have the tool do the modification. This seems like a weird exception though and doesn't really fit into our current model.

[JulienVdG]

Thanks for the answers.
Yes extract, edit, reassemble works and I've done a few tests with this approach but it's not a solution for a production tool.

1. Your point 1 should be easy to implement (as well as a summary of the top level layout as a different version of the table visitor).
   In my case I'm recovering the end of the ME region, but once I changed the IFDT (manually but I'm OK with that for now) it becomes a free space of the BIOS region (extended in IFDT) so it fit the case that the new FV must replace an empty region as represented by BIOSPadding.
   I'll think about it and probably go with that.

2. Yes I don't see a use case for nested FV, so we can ignore it (and error if user tries it)

3. I've tried to do 3 by editing the json, the result was that the firmware would fail... but I think I only tried it on the NVAR volumes... so this might still prove useful in some cases.
   One interface could be to select the FV by it's address and give it a new size, so exact same as point 1 except the initial content would be there and the tool will check that it extend only over BIOSPadding. (same limitation: will not handle nested FV).

[GanShun]

I can do a simple implementation for 1

[JulienVdG]

Firmware creation following option 1 above is implemented since #286 was merged !

[GanShun]

Thanks for doing that!