uefi: fs: Implement exists #135368

Ayush1325 · 2025-01-11T14:26:40Z

Also adds the initial file abstractions.

The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol.

After that, it queries all handles supporting
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat.

It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently.

DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators.

This is an effort to break the original PR (#129700) into much smaller chunks for faster upstreaming.

rustbot · 2025-01-11T14:26:49Z

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

jhpratt

ping @dvdhrm and @nicholasbishop as UEFI target maintainers. r=me with approval from either of them and the typo fixed.

library/std/src/sys/pal/uefi/fs.rs

nicholasbishop · 2025-01-12T03:20:08Z

There are still quite a few changes in this PR. For better review, could we break it up into some smaller pieces? For example, maybe we could start with a PR that just does some of the device-path helper changes.

Ayush1325 · 2025-01-12T04:09:39Z

There are still quite a few changes in this PR. For better review, could we break it up into some smaller pieces? For example, maybe we could start with a PR that just does some of the device-path helper changes.

Would it be fine to have some dead code with the cfg attribute? I can add the device path abstraction and the file open stuff separately in that case.

This PR is split off from rust-lang#135368 to reduce noise. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

Ayush1325 · 2025-01-12T04:39:39Z

There are still quite a few changes in this PR. For better review, could we break it up into some smaller pieces? For example, maybe we could start with a PR that just does some of the device-path helper changes.

I have moved the changes to the old DevicePath to a separate PR: #135393

It only contains stuff for OwnedDevicePath, but it should reduce all the noise due to renaming and refactoring from this PR.

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Introduce `device_path_to_text_raw` which creates a Box<[u16]> (UTF-16 string) from path instead of creating OsString. OsString internally is stored as WTF-8, which means converting OsString to Box<[u16]> requires allocation. This is not ideal for std::fs APIs where we need to perform Device Path Protocol matching while opening a volume, and create a UEFI UTF-16 string from the remaining path (which represents file path inside a volume). This remaining path is never used on the Rust side, and thus does not need to be converted to WTF-8 to be used. By introducing direct conversion to Box<[u16]>, we shorten the conversions from `EFI_DEVICE_PATH_PROTOCOL` -> WTF-8 -> UTF-16 to `EFI_DEVICE_PATH_PROTOCOL` -> UTF-16 which is required in every file open operation. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Introduce `device_path_to_text_raw` which creates a Box<[u16]> (UTF-16 string) from path instead of creating OsString. The UTF-16 returned by `EFI_DEVICE_PATH_TO_TEXT` protocol is owned by the caller, so we are just moving the memory management to box instead of freeing it in the function itself. OsString internally is stored as WTF-8, which means converting OsString to Box<[u16]> requires allocation. This is not ideal for std::fs APIs where we need to perform Device Path Protocol matching while opening a volume, and create a UEFI UTF-16 string from the remaining path (which represents file path inside a volume). This remaining path is never used on the Rust side, and thus does not need to be converted to WTF-8 to be used. By introducing direct conversion to Box<[u16]>, we shorten the conversions from `EFI_DEVICE_PATH_PROTOCOL` -> WTF-8 -> UTF-16 to `EFI_DEVICE_PATH_PROTOCOL` -> UTF-16 which is required in every file open operation. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Introduce `device_path_to_text_raw` which creates a Box<[u16]> (UTF-16 string) from path instead of creating OsString. The UTF-16 returned by `EFI_DEVICE_PATH_TO_TEXT` protocol is owned by the caller, so we are just moving the memory management to box instead of freeing it in the function itself. OsString internally is stored as WTF-8, which means converting OsString to Box<[u16]> requires allocation. This is not ideal for std::fs APIs where we need to perform Device Path Protocol matching while opening a volume, and create a UEFI UTF-16 string from the remaining path (which represents file path inside a volume). This remaining path is never used on the Rust side, and thus does not need to be converted to WTF-8 to be used. By introducing direct conversion to Box<[u16]>, we shorten the conversions from `EFI_DEVICE_PATH_PROTOCOL` -> WTF-8 -> UTF-16 to `EFI_DEVICE_PATH_PROTOCOL` -> UTF-16 which is required in every file open operation. That is, we remove 2 intermediate allocation and 1 UTF-16 validation. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [0]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment) Signed-off-by: Ayush Singh <ayush@beagleboard.org>

I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment) Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Introduce `device_path_to_text_raw` which creates a Box<[u16]> (UTF-16 string) from path instead of creating OsString. The UTF-16 returned by `EFI_DEVICE_PATH_TO_TEXT` protocol is owned by the caller, so we are just moving the memory management to box instead of freeing it in the function itself. OsString internally is stored as WTF-8, which means converting OsString to Box<[u16]> requires allocation. This is not ideal for std::fs APIs where we need to perform Device Path Protocol matching while opening a volume, and create a UEFI UTF-16 string from the remaining path (which represents file path inside a volume). This remaining path is never used on the Rust side, and thus does not need to be converted to WTF-8 to be used. By introducing direct conversion to Box<[u16]>, we shorten the conversions from `EFI_DEVICE_PATH_PROTOCOL` -> WTF-8 -> UTF-16 to `EFI_DEVICE_PATH_PROTOCOL` -> UTF-16 which is required in every file open operation. That is, we remove 2 intermediate allocation and 1 UTF-16 validation. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. Rename DevicePath to OwnedDevicePath. This is to allow a non-owning version of DevicePath in the future to work with UEFI shell APIs which provide const pointers to device paths for UEFI shell fs mapping. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment) Signed-off-by: Ayush Singh <ayush@beagleboard.org>

…ss35 path: Move is_absolute check to sys::path I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment)

This PR is split off from rust-lang#135368 to reduce noise. Rename DevicePath to OwnedDevicePath. This is to allow a non-owning version of DevicePath in the future to work with UEFI shell APIs which provide const pointers to device paths for UEFI shell fs mapping. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

uefi: helpers: Introduce OwnedDevicePath This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Also implement Debug for OwnedDevicePath for some quality of life improvements.

Rollup merge of rust-lang#135405 - Ayush1325:path-is-absolute, r=tgross35 path: Move is_absolute check to sys::path I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment)

Rollup merge of rust-lang#135393 - Ayush1325:uefi-helper-path, r=thomcc uefi: helpers: Introduce OwnedDevicePath This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Also implement Debug for OwnedDevicePath for some quality of life improvements.

bors · 2025-01-14T06:53:52Z

☔ The latest upstream changes (presumably #135465) made this pull request unmergeable. Please resolve the merge conflicts.

…pratt uefi: Implement path This PR is split off from rust-lang#135368 to reduce noise. UEFI paths can be of 4 types: 1. Absolute Shell Path: Uses shell mappings 2. Absolute Device Path: this is what we want 3. Relative root: path relative to the current root. 4. Relative Absolute shell path can be identified with `:` and Absolute Device path can be identified with `/`. Relative root path will start with `\`. The algorithm is mostly taken from edk2 UEFI shell implementation and is somewhat simple. Check for the path type in order. For Absolute Shell path, use `EFI_SHELL->GetDevicePathFromMap` to get a BorrowedDevicePath for the volume. For Relative paths, we use the current working directory to construct the new path. BorrowedDevicePath abstraction is needed to interact with `EFI_SHELL->GetDevicePathFromMap` which returns a Device Path Protocol with the lifetime of UEFI shell. Absolute Shell paths cannot exist if UEFI shell is missing. cc `@nicholasbishop`

Rollup merge of rust-lang#135475 - Ayush1325:uefi-absolute-path, r=jhpratt uefi: Implement path This PR is split off from rust-lang#135368 to reduce noise. UEFI paths can be of 4 types: 1. Absolute Shell Path: Uses shell mappings 2. Absolute Device Path: this is what we want 3. Relative root: path relative to the current root. 4. Relative Absolute shell path can be identified with `:` and Absolute Device path can be identified with `/`. Relative root path will start with `\`. The algorithm is mostly taken from edk2 UEFI shell implementation and is somewhat simple. Check for the path type in order. For Absolute Shell path, use `EFI_SHELL->GetDevicePathFromMap` to get a BorrowedDevicePath for the volume. For Relative paths, we use the current working directory to construct the new path. BorrowedDevicePath abstraction is needed to interact with `EFI_SHELL->GetDevicePathFromMap` which returns a Device Path Protocol with the lifetime of UEFI shell. Absolute Shell paths cannot exist if UEFI shell is missing. cc `@nicholasbishop`

uefi: Implement path This PR is split off from rust-lang/rust#135368 to reduce noise. UEFI paths can be of 4 types: 1. Absolute Shell Path: Uses shell mappings 2. Absolute Device Path: this is what we want 3. Relative root: path relative to the current root. 4. Relative Absolute shell path can be identified with `:` and Absolute Device path can be identified with `/`. Relative root path will start with `\`. The algorithm is mostly taken from edk2 UEFI shell implementation and is somewhat simple. Check for the path type in order. For Absolute Shell path, use `EFI_SHELL->GetDevicePathFromMap` to get a BorrowedDevicePath for the volume. For Relative paths, we use the current working directory to construct the new path. BorrowedDevicePath abstraction is needed to interact with `EFI_SHELL->GetDevicePathFromMap` which returns a Device Path Protocol with the lifetime of UEFI shell. Absolute Shell paths cannot exist if UEFI shell is missing. cc `@nicholasbishop`

Also adds the initial file abstractions. The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol. After that, it queries all handles supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat. It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently. DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

Ayush1325 · 2025-01-31T09:04:25Z

@nicholasbishop Does this PR seem manageable now?

nicholasbishop

Thanks for your patience, was out sick for a bit. Left a few comments, but I think it would still be helpful to break this down a little further, perhaps starting with DevicePathIterator.

nicholasbishop · 2025-02-08T17:46:18Z

library/std/src/sys/pal/uefi/fs.rs

+
+    impl File {
+        pub(crate) fn from_path(path: &Path, open_mode: u64, attr: u64) -> io::Result<Self> {
+            let absoulte = crate::path::absolute(path)?;


absoulte -> absolute

nicholasbishop · 2025-02-08T18:09:17Z

library/std/src/sys/pal/uefi/fs.rs

+            vol.open(&mut path_remaining, open_mode, attr)
+        }
+
+        fn open_volume_from_device_path(


Add a docstring, and include information about what's being returned. Include an example of the device path, e.g.

For example, given "PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Slave,0x0)/\abc\run.efi", this will open the volume ""PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Slave,0x0)" and return the remaining file path "\abc\run.efi".

Also, are there restrictions on path, like needing to be absolute? If so state that as well.

nicholasbishop · 2025-02-08T18:31:08Z

library/std/src/sys/pal/uefi/fs.rs

+        }
+    }
+
+    fn path_best_match<'a>(


Add docstring

nicholasbishop · 2025-02-08T18:32:48Z

library/std/src/sys/pal/uefi/fs.rs

+
+    fn path_best_match<'a>(
+        source: &helpers::BorrowedDevicePath<'a>,
+        target: &helpers::BorrowedDevicePath<'a>,


nit: <'_> and drop the named lifetime?

nicholasbishop · 2025-02-08T18:35:50Z

library/std/src/sys/pal/uefi/helpers.rs

@@ -330,6 +389,99 @@ impl<'a> crate::fmt::Debug for BorrowedDevicePath<'a> {
    }
 }

+pub(crate) struct DevicePathIterator<'a>(Option<DevicePathNode<'a>>);


Can you move the addition of the iterator to a separate PR?

Sure. I have limited bandwidth rn, so will do it in a few weeks.

I have created the PR: #137424