Handling support for EFI partitions

Forum for discussion about kernel-mode development.
Post Reply
Posts: 1
Joined: Thu Jul 19, 2018 4:44 am

Handling support for EFI partitions

Post by lundman » Thu Jul 19, 2018 5:12 am

Hello all!

Working on my own filesystem (OpenZFS) and I need to go back and address the issue with EFI partitions. When looking at a disk from one of the other platforms (illumos, linux, osx, freebsd) the ZFS pool disks have a normal MBR partition protecting the EFI label. So with Windows, using the API like IOCTL_DISK_GET_DRIVE_LAYOUT_EX, all I get is the gpt partition, and hence, PHYSICALDRIVE1 and that is it.

In my code I call libefi to read the EFI partition, looks like:

Code: Select all

read partitions ok 2
    gpt 0: type 8f7ee1d0 off 0x100000 len 0x13f600000
    gpt 1: type 8f7ee1d0 off 0x13f700000 len 0x800000

asking libefi to read label
EFI read OK, max partitions 9
    part 0:  offset 800:    len 9fb000:    tag: 4    name: 'zfs'
    part 1:  offset 9fb800:    len 4000:    tag: b    name: ''
At the moment, I hack that up and pass the device name to the kernel as "#partition-offset#partition-length#\\?\PHYSICALDRIVE0".

So it is time to fix that. I think it would be nice if I could call FindFirstVolume() / FindNextVolume(), and the 'zfs' partition would be one of them.

So, it is my guess (!) that I should write a driver that, using libefi, on any (unclaimed?) PHYSICALDRIVE and if I am able to read an EFI partitition of type 'zfs' (well, I guess proper code would support all partition types, but I only need zfs for now). create a virtual disk (somehow) and create a symlink like "PhysicalDrive0Partition1" or whatever the notation is. Then simply relay IO, making sure to offset the partition start?

Is that the best idea? Are there examples that mostly do this already? What would you do if you had to solve this?

Post Reply