Device behaves erractically after calling boot::open_protocol_exclusive::<DevicePath>

[Trolldemorted]

Thanks for giving us a nice API to UEFI! I have built a very simple demo app to test it, but my device (X12SPi-TF) behaves strangely after the app exits gracefully: I see the boot menu as expected, but I can neither start my app a second time, nor boot into the operating system on my NVMe (GRUB -> Ubuntu Server 2024). No matter what I select, after a brief glitch I get back to the boot menu. After a power reset the device works as expected again, and I can start the app once or boot into GRUB.

My app only attempts to open the DevicePath protocol on all handles that support the BlockIO protocol:

#[entry]
fn main() -> Status {
    uefi::helpers::init().unwrap();
    info!("uefitest starting up");
    test_bug().unwrap();
    boot::stall(10_000_000);
    Status::SUCCESS
}

fn test_bug() -> Result {
    info!("### Enumerating BlockIO handles ###");
    let block_io_handles = boot::locate_handle_buffer(SearchType::ByProtocol(&BlockIO::GUID)).unwrap();
    for handle in block_io_handles.iter() {
        let Ok(_device_path_proto) = boot::open_protocol_exclusive::<DevicePath>(*handle) else {
            continue;
        };
        info!("DevicePath proto opened");
    }

    Ok(())
}

I am testing with uefi 0.35.0 with the logger, panic_handler, alloc, and global_allocator feature (rustc 1.88.0).

Is there something obvious which I am missing, or could this be a firmware bug? I anticipated that an UEFI app could be started a second time, and that I could boot into a mundane OS after running an app. Do I need to reset the environment somehow before exiting? If I omit the boot::open_protocol_exclusive::<DevicePath> call and just loop over the BlockIO protocols, everything behaves as expected, and I can boot into GRUB as expected.