eif_extract utility to extract the ramdisk filesystem

[maayank]

We (Fireblocks) had several clients asking for ways to integrate the EIFs we supply with their own container/image scanning flows. We also have such use cases internally.

This PR includes a small refactoring of EifReader where the iteration over sections is done using a new Iterator that encapsulates the relevant parsing logic. This new iterator is then used to create a new eif_extract utility which receives an EIF and extracts the ramdisks. These can then be extracted using cpio and repacked using tar for maximum versatility.

In any case, I think it is a nice addition to the example utilities. I left the Cargo.toml in eif_extract as was on my PC, please modify accordingly/all feedback and changes are welcome.

Also added documentation.

Thanks, Maayan

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Example usage:

~/r/eif_extractor2 (master)> ./target/release/eif_extract example.eif out ramdisk
Starting extraction process...
Reading section data...
Saved ramdisk to out/ramdisk0.dat
Saved ramdisk to out/ramdisk1.dat
Extraction completed successfully.
Successfully extracted ramdisks to 'out'
~/r/eif_extractor2 (master)> ls -alh out
total 450M
drwxrwxr-x 2 maayan maayan 4.0K Aug  1 00:35 .
drwxrwxr-x 7 maayan maayan 4.0K Aug  1 00:35 ..
-rw-rw-r-- 1 maayan maayan 746K Aug  1 00:35 ramdisk0.dat
-rw-rw-r-- 1 maayan maayan 449M Aug  1 00:35 ramdisk1.dat

[sabin-rapan]

Hey @maayank , thank you for the PR. Would you mind adding your Signed-off-by line to each commit via git commit -s. Just so commits consistent with the rest in this repo. Also, commits 1 and 2 should be squashed together since they are part of the same logical change. The same goes for commits 3 and 4.

[maayank]

Hey @sabin-rapan , thanks for the quick and prompt reply. Done! :)

[sabin-rapan]

There's also https://github.com/aws/aws-nitro-enclaves-image-format/pull/26 to be taken into consideration for this PR.

[maayank]

@sabin-rapan Re: #26 - started to implement something similar in my branch. CRCing the gaps during iteration is a bit more tricky if I separate the iteration logic out of the EifReader class. Since piece-wise CRCing all of the sectors and their gaps is equivalent to just CRCing everything after the header at once[1], I was thinking of just CRCing the whole eif together in another pass. WDYT? Much simpler code, but another pass of the EIF.

[1] i.e.

crc.update(A)
crc.update(B)

is the same as crc.update(A + B)

[sabin-rapan]

@sabin-rapan Re: #26 - started to implement something similar in my branch. CRCing the gaps during iteration is a bit more tricky if I separate the iteration logic out of the EifReader class. Since piece-wise CRCing all of the sectors and their gaps is equivalent to just CRCing everything after the header at once[1], I was thinking of just CRCing the whole eif together in another pass. WDYT? Much simpler code, but another pass of the EIF.

[1] i.e.

crc.update(A)
crc.update(B)

is the same as crc.update(A + B)

Functionally wise sounds okay, but I haven't fully wrapped my head around the use-case of gaps in EIF files. Maybe piggyback data from one party (EIF producer) to another party (EIF user) so that the latter can validate something with the data in those gaps?

CC: @foersleo

[maayank]

Hey @sabin-rapan , @foersleo , I wanted to follow up on this PR to see if there's anything further needed from my end. The current PR doesn't change the current behavior on the main branch. If you'd like, maybe we can merge this and then I'll issue a separate PR for the CRC and eif utility unification? WDYT?