On Feb 12, 2013, at 2:50 PM, "Kinney, Michael D" <michael.d.kin...@intel.com> wrote:
> David, > > It Is possible to use the UEFI Driver Model to create a filter driver for any > protocol. The method is to open the protocol the needs to be filtered > BY_DRIVER and produces a child handle with the same protocol interface with > filter logic in the filter driver implementation along with a new Device Path > Protocol instance that is a copy of the original device path plus an extra > device path node that would usually be a VenHw() device path node. Since > your filter opened BY_DRIVER, no other driver can open it. The rest of the > UEFI Driver services that would have opened the original protocol will now > open your filtered protocol. > > This method requires the filter driver to connect to the protocol that needs > to be filtered first. You can use the ConnectController() precedence rules > that Andrew listed below. The other option is to use an open mode of > BY_DRIVER | EXCLUSIVE. The EXCLUSIVE flag attempts to kick off all other > drivers off that protocol first. If that open succeeds, then you can create > your child handle with your filtered protocol. If the open fails, then you > can not provide a filter for that specific protocol. > > The only other caution on this design is that you need to prevent an infinite > recursion of your filter when it tries to filter the filter. You can install > an extra protocol on your child handle (usually gEfiCallerIdGuid of your > filter driver), and your Start() function should ignore handles that already > have your gEfiCallerIdGuid protocol installed. > Thanks Mike you beat me to it. The only thing I was going to add is the firmware usually carries a partition driver and a FAT32 driver. What you want is for these drivers to layer on your filter driver. I think the OS is going to look for the short form device path that starts with the Hard Drive node, and this handle is going to be created by the partition driver. UEFI 2.3.1 section 3.1.2 The boot manager must also support booting from a short-form device path that starts with the first element being a hard drive media device path (see Table 74). The boot manager must use the GUID or signature and partition number in the hard drive device path to match it to a device in the system. If the drive supports the GPT partitioning scheme the GUID in the hard drive media device path is compared with the UniquePartitionGuid field of the GUID Partition Entry (see Table 17). If the drive supports the PC-AT MBR scheme the signature in the hard drive media device path is compared with the UniqueMBRSignature in the Legacy Master Boot Record (see Table 12). If a signature match is made, then the partition number must also be matched. The hard drive device path can be appended to the matching hardware device path and normal boot behavior can then be used. If more than one device matches the hard drive device path, the boot manager will pick one arbitrarily. Thus the operating system must ensure the uniqueness of the signatures on hard drives to guarantee deterministic boot behavior. A driver that creates a child handle is called a bus driver in UEFI. You can read about this in the UEFI Driver Writer's Guide http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Driver_Developer On your child handle with the filtered Block IO you are going to want to copy the device path of the hardware block IO device and append your own device path node. You can use a Vendor-Defined Media Device Path for your node. Good Luck, Andrew > Best regards, > > Mike > > -----Original Message----- > From: David Wu [mailto:david.wu8...@sbcglobal.net] > Sent: Tuesday, February 12, 2013 10:50 AM > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] block I/O protocol filter driver > > 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 ------------------------------------------------------------------------------ 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
