Skip to content
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

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from
65 changes: 56 additions & 9 deletions rust/uefi/stub/src/thin.rs
Original file line number Diff line number Diff line change
@@ -1,6 +1,8 @@
use log::{error, warn};
use sha2::{Digest, Sha256};
use uefi::{fs::FileSystem, prelude::*, CString16, Result};
use uefi::{fs::FileSystem, proto::loaded_image::LoadedImage, prelude::*, CStr16, CString16, Result};
use uefi::proto::network::IpAddress;
use uefi::proto::network::pxe::{BaseCode, DhcpV4Packet};

use crate::common::{boot_linux_unchecked, extract_string, get_cmdline, get_secure_boot_status};
use linux_bootloader::pe_section::pe_section;
Expand Down Expand Up @@ -93,8 +95,8 @@ pub fn boot_linux(handle: Handle, mut system_table: SystemTable<Boot>) -> uefi::

let secure_boot_enabled = get_secure_boot_status(system_table.runtime_services());

let kernel_data;
let initrd_data;
let mut kernel_data;
let mut initrd_data;

{
let file_system = system_table
Expand All @@ -103,12 +105,57 @@ pub fn boot_linux(handle: Handle, mut system_table: SystemTable<Boot>) -> uefi::
.expect("Failed to get file system handle");
let mut file_system = FileSystem::new(file_system);

kernel_data = file_system
.read(&*config.kernel_filename)
.expect("Failed to read kernel file into memory");
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() {
Copy link
Member

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?

Copy link
Member Author

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 mut file_system = system_table
.boot_services()
.get_image_file_system(handle)
.expect("Failed to get file system handle");

kernel_data = file_system
.read(&*config.kernel_filename)
.expect("Failed to read kernel file into memory");
initrd_data = file_system
.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())
Copy link
Member

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, will do so!

.expect("Failed to open the loaded image protocol on the currently loaded image");

let mut base_code = system_table.boot_services().open_protocol_exclusive::<BaseCode>(loaded_image_protocol.device()).unwrap();

assert!(base_code.mode().dhcp_ack_received);
let dhcp_ack: &DhcpV4Packet = base_code.mode().dhcp_ack.as_ref();
let server_ip = dhcp_ack.bootp_si_addr;
let server_ip = IpAddress::new_v4(server_ip);

let kernel_filename = cstr8!("./bzImage");
Copy link
Member Author

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…

Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

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.

let initrd_filename = cstr8!("./initrd");

let kfile_size = base_code
.tftp_get_file_size(&server_ip, kernel_filename)
.expect("failed to query file size");

let ifile_size = base_code
.tftp_get_file_size(&server_ip, initrd_filename)
.expect("failed to query file size");

assert!(kfile_size > 0);
Copy link
Member Author

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.

assert!(ifile_size > 0);

kernel_data = Vec::with_capacity(kfile_size as usize);
kernel_data.resize(kfile_size as usize, 0);
Comment on lines +145 to +146
Copy link
Member

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.

initrd_data = Vec::with_capacity(ifile_size as usize);
initrd_data.resize(ifile_size as usize, 0);
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");
Comment on lines +149 to +154
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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. 😂


assert!(klen > 0);
assert!(ilen > 0);
}
}

let cmdline = get_cmdline(
Expand Down