-
Notifications
You must be signed in to change notification settings - Fork 18
eif_extract utility to extract the ramdisk filesystem #29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Hey @maayank , thank you for the PR. Would you mind adding your Signed-off-by line to each commit via |
efc88b0
to
558bc7f
Compare
Hey @sabin-rapan , thanks for the quick and prompt reply. Done! :) |
Ok(()) | ||
} | ||
|
||
fn main() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something worth considering is to merge eif-extract and eif-build into a single applcation "eif" with build and extract subcommands. This way it would be easier for users to consume both, and to maintain as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, will add this tomorrow and then squash.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see PR #31 - I prefer to merge the two utilities only once that PR is merged, since it makes significant changes to eif_builder. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me
The iterator returns the section header, section header buffer, and the section buffer for each sector. Signed-off-by: Maayan Keshet <[email protected]>
This commit introduces the eif_extract utility, which is used to extract the ramdisk sections from EIF files. Usage examples and a detailed description have been added to README. Signed-off-by: Maayan Keshet <[email protected]>
There's also #26 to be taken into consideration for this PR. |
@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.
is the same as crc.update(A + B) |
eif_extract/src/main.rs
Outdated
let mut ramdisk_count = 0; | ||
|
||
println!("Reading section data..."); | ||
for section in sections.filter_map(|x| x.ok()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here filter_map(|x| x.ok())
will hide the sections that couldn't be read for whatever reason, which doesn't sound like the right thing to do for an eif extract
command. Likely the user would like to know if an error happened and for the program to exit in this case. Otherwise it would be too easy to trick ourselves into thinking we extracted all the ramdisks.
I think you can do:
for section in sections {
let section = section.map_err(|e| io::Error::new(io::ErrorKind::Other, format!("Unable to read section: {:?}", e)))?;
// and then do the if == EifSectionType::EifSectionRamdisk
}
This is not compile-tested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done! :)
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 |
- Use section fields in the EIF header for iteration - Introduce EifSector to represent coupled header and buffer - Fix missing CRC update by section data Signed-off-by: Maayan Keshet <[email protected]>
Hey @sabin-rapan , @foersleo , |
// Extract the ramdisks | ||
if let Err(e) = extract_ramdisks(eif_path, output_dir, prefix) { | ||
eprintln!("Failed to extract ramdisks: {}", e); | ||
} else { | ||
println!("Successfully extracted ramdisks to '{}'", output_dir); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tool should be able to extract all bits of data from an EIF file. As a full counterpart to eif_build
, it should allow you to take an EIF, extract everything and then allow you to call eif_build
with the relevant inputs to reassemble a (functionally) identical EIF.
let eif_path = &args[1]; | ||
let output_dir = &args[2]; | ||
let prefix = &args[3]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eif_build
uses clap for command line parsing. Especially considering that we want to merge eif_build
and eif_extract
into a single eif
tool with subarguments build
and extract
, we need to make sure we converge on the command line experience early on. So please use clap here as well :).
### eif_extract | ||
|
||
You can use the `eif_extract` tool to extract artifacts (e.g. for scanning) from an AWS Nitro Enclave image file: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've learned recently that cargo.io wants subprojects to have their own creates.io submission which then includes a separate README file in their own directory. See PR #35 for reference. Would you mind to follow the same pattern for eif_extract
?
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: