Netboot support #227

RaitoBezarius · 2023-09-24T17:59:50Z

Summary:

enables lzbt build with the systemd tool to produce one-off stubs that can be built inside of a Nix derivation
enable the thin stub to transfer control if booted via netboot (the fat stub should work out of the box because it contains all it needs and doesn't require further FS access) reusing PXE base code protocol
add a crude netboot test using NixOS test framework

RaitoBezarius · 2023-09-24T18:00:52Z

rust/tool/systemd/src/cli.rs

@@ -99,3 +120,48 @@ fn install(args: InstallCommand) -> Result<()> {
 )
 .install()
 }
+
+fn build(args: BuildCommand) -> Result<()> {


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.

#204 went in. Looking forward to the simpler version. :)

RaitoBezarius · 2023-09-24T18:01:30Z

rust/uefi/stub/src/thin.rs

+ let server_ip = dhcp_ack.bootp_si_addr;
+ let server_ip = IpAddress::new_v4(server_ip);
+
+ let kernel_filename = cstr8!("./bzImage");


Ideally, we should use the embedded paths in the binary, which bring the burning question
on how do you encode those properly…

What problems do you anticipate when loading the filenames from the binary?

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)?

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.

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.

RaitoBezarius · 2023-09-24T18:01:59Z

rust/uefi/stub/src/thin.rs

+ .tftp_get_file_size(&server_ip, initrd_filename)
+ .expect("failed to query file size");
+
+ assert!(kfile_size > 0);


In case of failure, this would be good to just reboot because then the PXE process can get a new chance to succeed.

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.

blitz · 2023-11-10T14:43:49Z

rust/uefi/stub/src/thin.rs

- 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() {


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?

We don't have a simple filesystem if we are booted from a non-filesystem, e.g. network!

blitz · 2023-11-10T14:44:54Z

rust/uefi/stub/src/thin.rs

+ let server_ip = dhcp_ack.bootp_si_addr;
+ let server_ip = IpAddress::new_v4(server_ip);
+
+ let kernel_filename = cstr8!("./bzImage");


What problems do you anticipate when loading the filenames from the binary?

blitz · 2023-11-10T14:46:47Z

rust/uefi/stub/src/thin.rs

+ kernel_data = Vec::with_capacity(kfile_size as usize);
+ kernel_data.resize(kfile_size as usize, 0);


These can be vec![0; kfile_size as usize]. Clippy should tell you this as well.

blitz · 2023-11-10T14:48:51Z

rust/uefi/stub/src/thin.rs

+ .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())


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. :)

Gotcha, will do so!

blitz

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.

blitz · 2023-11-10T14:50:17Z

rust/uefi/stub/src/thin.rs

+ 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");


Should we bother with TFTP? Recent UEFI should also do HTTP just fine and it's much faster.

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?

Not sure, maybe. But it would be weird. 😂

blitz · 2023-11-10T14:53:02Z

rust/tool/systemd/src/cli.rs

@@ -99,3 +120,48 @@ fn install(args: InstallCommand) -> Result<()> {
 )
 .install()
 }
+
+fn build(args: BuildCommand) -> Result<()> {


#204 went in. Looking forward to the simpler version. :)

RaitoBezarius requested a review from nikstur September 24, 2023 17:59

RaitoBezarius commented Sep 24, 2023

View reviewed changes

RaitoBezarius requested a review from blitz September 24, 2023 18:02

RaitoBezarius force-pushed the netboot branch from 65d0160 to ea7ba52 Compare September 24, 2023 18:03

RaitoBezarius added this to the Release 0.5.0 milestone Sep 30, 2023

RaitoBezarius force-pushed the netboot branch from ea7ba52 to 58a1c0c Compare October 30, 2023 12:17

RaitoBezarius added 6 commits October 30, 2023 13:47

tool(systemd): move assemble_kernel_cmdline in the shared crate

4dffe15

This is a generic utility.

tool(shared): load generation from a toplevel path

1622437

We do not necessarily build stubs out of profiles, sometimes, out of bare toplevel paths.

tool(systemd): introduce lzbt build to build stubs on the command line

fd7b0e5

This is useful when you want to build a netboot stub which will continue the control after being PXE booted.

nix/tests/lanzaboote: perform crude netboot testing [NOT FOR FINAL ME…

7877fb6

…RGE] This is a crude way to do netboot testing.

RaitoBezarius force-pushed the netboot branch from 58a1c0c to 7877fb6 Compare October 30, 2023 12:47

blitz reviewed Nov 10, 2023

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Netboot support #227

Netboot support #227

RaitoBezarius commented Sep 24, 2023

RaitoBezarius Sep 24, 2023

blitz Nov 10, 2023

RaitoBezarius Sep 24, 2023

blitz Nov 10, 2023

RaitoBezarius Nov 10, 2023

blitz Nov 10, 2023

RaitoBezarius Nov 10, 2023

RaitoBezarius Sep 24, 2023

blitz Nov 10, 2023

RaitoBezarius Nov 10, 2023

blitz Nov 10, 2023

blitz Nov 10, 2023

blitz Nov 10, 2023

RaitoBezarius Nov 10, 2023

blitz left a comment

blitz Nov 10, 2023

RaitoBezarius Nov 10, 2023

blitz Nov 12, 2023

blitz Nov 10, 2023

		kernel_data = Vec::with_capacity(kfile_size as usize);
		kernel_data.resize(kfile_size as usize, 0);

Netboot support #227

Are you sure you want to change the base?

Netboot support #227

Conversation

RaitoBezarius commented Sep 24, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blitz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment