-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
Netboot support #227
base: master
Are you sure you want to change the base?
Netboot support #227
Conversation
@@ -99,3 +120,48 @@ fn install(args: InstallCommand) -> Result<()> { | |||
) | |||
.install() | |||
} | |||
|
|||
fn build(args: BuildCommand) -> Result<()> { |
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 tried to make this simple but failed because install is very focused on install semantics
and hard to generalize.
With #204, I imagine I can simplify a lot all this stuff.
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.
#204 went in. Looking forward to the simpler version. :)
let server_ip = dhcp_ack.bootp_si_addr; | ||
let server_ip = IpAddress::new_v4(server_ip); | ||
|
||
let kernel_filename = cstr8!("./bzImage"); |
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.
Ideally, we should use the embedded paths in the binary, which bring the burning question
on how do you encode those properly…
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.
What problems do you anticipate when loading the filenames from the binary?
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.
What is the path format you want to adopt for referring to filenames that can come from a non-filesystem, e.g. remote network locations?
Do we assume that we always load relative to the root of whatever "filesystem" (be it network or local)?
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.
What is the path format you want to adopt for referring to filenames that can come from a non-filesystem, e.g. remote network locations?
Could we use URLs? tftp://some-server/some-file? This would also map nicely to HTTP later. The only wart is that we would have to invent a special hostname for the BOOTP server we get via DHCP.
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.
In that case, we would need to assert that some-server == the server who loaded this current image
, right?
Otherwise, as you can see in the code, I would need to re-open the TFTP operations socket, etc. I don't think we have DNS BTW, do we? We would need IP addresses.
And we would not be able to encode anything like credential or whatever.
.tftp_get_file_size(&server_ip, initrd_filename) | ||
.expect("failed to query file size"); | ||
|
||
assert!(kfile_size > 0); |
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.
In case of failure, this would be good to just reboot because then the PXE process can get a new chance to succeed.
65d0160
to
ea7ba52
Compare
ea7ba52
to
58a1c0c
Compare
This is a generic utility.
We do not necessarily build stubs out of profiles, sometimes, out of bare toplevel paths.
Usually, we build towards a certain ESP in our model. Sometimes, we don't know in advance our ESP or don't care about this (building a stub that can be streamed, netbooted, etc.). This is a trivial implementation of a set of "build tree" ESP paths, e.g. no GC and only a root path where everything is in together.
This is useful when you want to build a netboot stub which will continue the control after being PXE booted.
In situations where we are not booted by a local filesystem, the SFS won't be available. But we can try to look if we have been booted by a PXE API and get the protocol to look for remote files that can enable us to continue the boot process while not breaking the Secure Boot guarantees.
…RGE] This is a crude way to do netboot testing.
58a1c0c
to
7877fb6
Compare
initrd_data = file_system | ||
.read(&*config.initrd_filename) | ||
.expect("Failed to read initrd file into memory"); | ||
if system_table.boot_services().test_protocol::<uefi::proto::media::fs::SimpleFileSystem>(filesystem_protocol_params).is_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.
It seems a bit magic how you decide to fall into the netboot code. What's the secret here? :) Should this be part of some configuration baked into the binary?
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.
We don't have a simple filesystem if we are booted from a non-filesystem, e.g. network!
let server_ip = dhcp_ack.bootp_si_addr; | ||
let server_ip = IpAddress::new_v4(server_ip); | ||
|
||
let kernel_filename = cstr8!("./bzImage"); |
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.
What problems do you anticipate when loading the filenames from the binary?
kernel_data = Vec::with_capacity(kfile_size as usize); | ||
kernel_data.resize(kfile_size as usize, 0); |
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.
These can be vec![0; kfile_size as usize]
. Clippy should tell you this as well.
.read(&*config.initrd_filename) | ||
.expect("Failed to read initrd file into memory"); | ||
} else { | ||
let loaded_image_protocol = system_table.boot_services().open_protocol_exclusive::<LoadedImage>(system_table.boot_services().image_handle()) |
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.
super nit: Refering to the protocol as pxe::BaseCode
instead of BaseCode
would have saved me some time figuring out where this protocol comes from. :)
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.
Gotcha, will do so!
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 mostly looked at the stub changes. Implementation-wise I think this is pretty straight-forward. I would mostly be concerned with how the stub makes the decision to network boot.
let klen = base_code | ||
.tftp_read_file(&server_ip, kernel_filename, Some(&mut kernel_data)) | ||
.expect("failed to read file"); | ||
let ilen = base_code | ||
.tftp_read_file(&server_ip, initrd_filename, Some(&mut initrd_data)) | ||
.expect("failed to read 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.
Should we bother with TFTP? Recent UEFI should also do HTTP just fine and it's much faster.
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.
But if you are loaded from a TFTP server, you need to use TFTP? In practice, in my tests, HTTP is not really available I think?
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.
Not sure, maybe. But it would be weird. 😂
@@ -99,3 +120,48 @@ fn install(args: InstallCommand) -> Result<()> { | |||
) | |||
.install() | |||
} | |||
|
|||
fn build(args: BuildCommand) -> Result<()> { |
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.
#204 went in. Looking forward to the simpler version. :)
Summary:
lzbt build
with the systemd tool to produce one-off stubs that can be built inside of a Nix derivation