Hi Andrew, Thank you very much for your input. You ask me why I need to filter the data and what problem I'm trying to solve. I need to decrypt the hibernation file during hibernation resuming. We encrypt the hibernation file hiberfil.sys during hibernation preparing. So we need to decrypt it during resuming. In legacy BIOS, hibernation file is read back via INT 13H during resuming. So, I decrypt it via INT 13h hook when hibernation file disk offset is matched. But in UEFI, it is read back via block I/O protocol. That is why I'm seeking the possibility to using block I/O protocol filter. I tried on Dump_Read() in Windows hibernation dump filter also( http://msdn.microsoft.com/en-us/library/windows/hardware/hh439713(v=vs.85).aspx. ) But it doesn't work.
Any advise in that case? Thanks again. David ----- Original Message ---- From: Andrew Fish <af...@apple.com> To: edk2-devel@lists.sourceforge.net Sent: Tue, February 12, 2013 11:09:44 AM Subject: Re: [edk2] block I/O protocol filter driver On Feb 11, 2013, at 7:34 PM, David Wu <david.wu8...@sbcglobal.net> wrote: > Hello, > Since UEFI systems use block I/O protocol to read data instead of INT 13h > under legacy BIOS, we need to migrate our hibernation resuming filter driver > under legacy BIOS to UEFI enviroment. With almost zero previous knowledge on > EFI and by reading UEFI specificantion 2.3.1, I feel that block I/O > protoclol filter driver could be a solution to filtering hibernation file > during hibernation resuming. However, UEFI Driver Writer's Guide doesn't > appear to contain a section on block I/O protocol filter driver. > I'd recommend you read the driver writers guide. http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Driver_Developer > > So, my questions are: > 1. Is it possible to replace legacy BIOS INT 13h hook with block I/O > protocol filter driver under UEFI system to filter hibernation resuming > file? There is not a standard way to filter. Drivers produce interfaces on handles. Which driver gets used is based on the precedence rules. This functions uses five precedence rules when deciding the order that drivers are tested against controllers. These five rules from highest precedence to lowest precedence are as follows: 1. Context Override : DriverImageHandle is an ordered list of handles that support the EFI_DRIVER_BINDING_PROTOCOL. The highest priority image handle is the first element of the list, and the lowest priority image handle is the last element of the list. The list is terminated with a NULL image handle. 2. Platform Driver Override : If an EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL instance is present in the system, then the GetDriver() service of this protocol is used to retrieve an ordered list of image handles for ControllerHandle. >From this list, the image handles found in rule (1) above are removed. The first image handle returned from GetDriver() has the highest precedence, and the last image handle returned from GetDriver() has the lowest precedence. The ordered list is terminated when GetDriver() returns EFI_NOT_FOUND. It is legal for no image handles to be returned by GetDriver(). There can be at most a single instance in the system of the EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL. If there is more than one, then the system behavior is not deterministic. 3. Driver Family Override Search : The list of available driver image handles can be found by using the boot service LocateHandle()with a SearchType of ByProtocol for the GUID of the EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL. From this list, the image handles found in rules (1), and (2) above are removed. The remaining image handles are sorted from highest to lowest based on the value returned from the GetVersion() function of the EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL associated with each image handle. 4. Bus Specific Driver Override : If there is an instance of the EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL attached to ControllerHandle, then the GetDriver() service of this protocol is used to retrieve an ordered list of image handle for ControllerHandle. From this list, the image handles found in rules (1), (2), and (3) above are removed. The first image handle returned from GetDriver() has the highest precedence, and the last image handle returned from GetDriver() has the lowest precedence. The ordered list is terminated when GetDriver() returns EFI_NOT_FOUND. It is legal for no image handles to be returned by GetDriver(). 5. Driver Binding Search : The list of available driver image handles can be found by using the boot service LocateHandle() with a SearchType of ByProtocol for the GUID of the EFI_DRIVER_BINDING_PROTOCOL. From this list, the image handles found in rules (1), (2), (3), and (4) above are removed. The remaining image handles are sorted from highest to lowest based on the Version field of the EFI_DRIVER_BINDING_PROTOCOL instance associated with each image handle. > 2. If the answer for question 1 is yes, then what are basic steps to > register a block I/O protocol filter so that other drivers can attach to new > protocol driver? I'm not sure it is possible. You need to do the OpenProtocol() and produce the Driver Binding protocol. You can't just reinstall some one else's protocol. It may be possible to get yourself in the chain an put stuff back before the DriverBinding.Stop() is called on the real BlockIo driver. > 3. If I get the block io protocol by using HandleProtocol(), and allocate a > structure containing my EFI_BLOCK_IO interface and a pointer to original > block read function, will ReinstallProtocolInterface() detach existing > consumers and then signaling drivers to attach to the new protocol > interface? > No this will not work. There is an assumption that the reinstall happens from within the block IO driver, see the Drivers Writers Guide. > Any advise or suggestion would be appreciated. > Why do you need to filter the data. What problem are you trying to solve? It may be better to use the precedence rules to replace another driver. Thanks, Andrew Fish > Thanks > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
