UEFI boot and sanhook

[parthy]

Oh yes, sorry. What I would like to do is use iPXE to hook an iSCSI disk, and then access it from within an EFI application. On legacy systems, this used to work. The kernel that was loaded by iPXE could just execute BIOS calls to read from the disk, and iPXE would get the data from the network. I am wondering if the same mechanism is feasible on UEFI.

Here is my iPXE config:

Code:

#!ipxe

set username <secret>
set password <secret>

set keep-san 1
set initiator-iqn <custom-prefix>:${net0/mac:hexhyp}

set iscsi-server ${next-server}

set san-filename \EFI\boot\bootx64.efi

set root-path iscsi:${iscsi-server}::3260:1:iqn.xxxx-yy.de.foo.iscsi:<target_name>

sanhook --drive 0x80 ${root-path} || goto fail

chain shellx64.efi

:fail
shell

When booting this in qemu with OVMF/TianoCore, I get the following:

Code:

EFI Shell version 2.70 [1.0]
Current running mode 1.1.2
EFIBLK 0x80 flush
EFIBLK 0x80 flush
EFIBLK 0x80 flush
EFIBLK 0x80 flush
EFIBLK 0x80 flush
EFIBLK 0x80 read LBA 0x00000000 to 0x7e113798+0x00000200
map: Cannot find required map name.

Press ESC in 1 seconds to skip startup.nsh, any other key to continue.
Shell>

When I boot it on real hardware, I see the partitions appear, but running ls in any of them again hangs.

The hint about the network being interrupted might be the key, though. In the shell, I indeed see the network interface unconfigured. Is there anything I need to to in order for the application to access the hooked disk?

---

Quick update: If I use snponly.efi, it works in the shell.

The way I see it, the shutdown_boot() call when loading Multiboot binaries severs the network connection. How does this work on legacy systems? The iSCSI connection survives there somehow, until the OS takes over.