Hi, I just implemented an UEFI filter driver for the BlockIO protocol. The intention of this driver is to provide an encryption/decryption driver for a block device (disk partition). I followed the hints as given in this thread: http://comments.gmane.org/gmane.comp.bios.tianocore.devel/2003 Unfortunately the Windows UEFI boot loader seems to ignore the filter driver and boots from the device without filter. In that case that means that Windows tries to boot from the encrypted partition. Has anybody any idea how to bring Windows to connect to the filter driver while booting? Here are the details how the driver works:
When the driver is connected to the controller (the controller must provide the BlockIo protocol) then the driver first opens the BlockIo protocol of the controller in mode EFI_OPEN_PROTOCOL_BY_DRIVER | EFI_OPEN_PROTOCOL_EXCLUSIVE. Then a child device node is created by the driver that provides the BlockIo protocol. This BlockIo protocol interface implements the filter function of the driver. When now another EFI driver or EFI application connects to the child node then the BlockIo protocol provides the filtered result: In my case the filter makes a decryption or encryption of the content of the BlockIo of the parent node (the controller). When another EFI driver or EFI application connects to the parent node, then the BlockIo protocol provides the original data (without the filter driver). This was tested using the EFI shell and seems to work properly. Beside of the BlockIo protocol, the child node also provides some other protocols: the DevicePathProtocol and ComponentNameProtocol. In the DevicePathProtocol, the type of node is encoded. I tried with Type = MEDIA_DEVICE_PATH, SubType = MEDIA_FILEPATH_DP and with Type = HARDWARE_DEVICE_PATH, SubType = HW_VENDOR_DP. All that cases are working in the EFI shell as described above, but when I try to boot Windows 8.1 from an encrypted partition, it does not work. Here is how I tested it with Windows: First I tried to boot Windows from the encrypted partition without the EFI filter driver. As expected, the boot process stops very early with a blue screen. Then I enabled the filter driver and booted again. Since Windows did not have its own crypto device driver, I expected that it will crash as well, but later as in the first case because the Windows EFI loader can use the filter driver to access the disk and read and start the kernel. But unfortunately this was not observed: Instead, the boot process stopped at same position as without the filter driver and with the same error messages. This means to me, that Windows does not connect its EFI loader to the provided child node of the partition device, it seems to use the parent node that does not use the filter driver for the BlockIo protocol. So the question for me is: How can I force the Windows EFI boot loader (bootmgfw.efi) to use the filter driver for the BlockIo protocol? My speculation goes in the following direction: (1) Maybe the Windows EFI boot loader never uses child device nodes, it explicitely uses the partition device and uses its BlockIo protocol. In this case I have no idea how to design the filter driver since the BlockIo protocol of the parent device is required to access the partition data and cannot be replaced by the flter driver BlockIo protocol. Also, this device can only provide one instance of the BlockIo protocol and not two. One possibility might be to remove the BlockIo Protocol of the parent device (the partition) and redesign the filter driver in the way that it consumes the DiskIo protocol instead of the BlockIo and provides the BlockIo at the parent device that implements the filter functionality. Besides the filter functionality, the transformation of the BlockIo protocol to the DiskIo function must be implemented. (2) Maybe the Windows EFI boot loader is able to access the child node, but only for dedicated device Type/Subtype combinations (as defined by DevicePathProtocol). (3) Maybe it is possible to explicitly tell the Windows EFI boot loader to use the child node. This is usually done using the BCDEdit tool under Windows where such settings are made. In fact, the boot device can be set with that tool. The syntax of this tool accepts definitions like partition=\Device\HarddiskVolume4, which seems to correspond to a dedicated EFI partition device. Unfortunately the tool does not accept to extend the path \Device\HarddiskVolume4 to address the child device path, like \Device\HarddiskVolume4\crypto. This is not accepted by BCDedit. Hence, the question is how this can be configured. Thanks Falk _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
