The Client Solution Policy DLL is provided by the Client. OSR includes a complete and well-documented sample Policy DLL (SampPolicy) that Clients can use as the basis for their own implementation. See the FESF Sample Solution Guide for more information on the OSR-provided sample code.
As previously described, the Client Solution's Policy DLL is the primary interface point between FESF and the Client's product implementation. Except for the initialization callback which is always called by name, callback functions in the Policy DLL are called by pointer. The Policy DLL passes pointers to each of its callback functions during initialization processing. After initialization, FESF calls callback functions in the Policy DLL to determine policy for a particular open instance of a file, as well as to retrieve the Policy DLL defined Header Data and Key data for files that are to be encrypted/decrypted by FESF.
As an example of how things work, consider the Policy DLL's PolGetPolicyNewFile function. This function is called whenever a new file is being created on a supported file system. After the CreateFile has been successfully processed by the target file system but before the user's call to open the file has completed, the FESF Policy Service calls the Policy DLL's PolGetPolicyNewFile callback function to determine if data subsequently written to this file should be encrypted. If PolGetPolicyNewFIle indicates that the file is to be encrypted, FESF calls the Policy DLL's PolGetKeyNewFile to retrieve the Algorithm ID, Key, and Policy DLL specific Header Data to be stored with the file to allow the file to be decrypted at a later time. During the call into the Policy DLL, the user application that called CreateFile (and the kernel-mode mechanism associated with this operation) is blocked, waiting, until both PolGetPolicyNewFile and PolGetKeyNewFile return. As a result, all processing done in the Policy DLL must be prompt.
Processing for other callbacks in the Solution's Policy DLL work similarly. The calls to PolGetPolicyExistingFile, and PolGetKeyFromHeader take place after the application's CreateFile operation has been processed by the file system on which the file is located, but before the application is informed of the result. Again, this call into the Client's Policy DLL is blocking completion of Windows' kernel mode processing of this open operation and ultimately the application's further progress.