A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about kernel-mode development.
 #31862  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?