It appears to me that a file system server providing a file to a client always belongs to that client's trusted computing base. The FS server has to belong to the client's TCB, because it will provide the client with the content of a file. It may alter that content in any possible way before handing it to the client.
Given that trust relationship, the revocation of pages may or may not be part of the protocol the client and the server agreed upon. If no pages shall be revoked, the client *knows* that the server will not revoke pages, because the client trusts the server.
Therefore, the FS server can be the DM for the file, the client requested: No need to drop that approach.
Data integrity is an orthogonal issue from providing data (i.e. transferring it) and holding data (e.g. mapping). Data integrity can be guaranteed using cryptographic means. (Indeed, confidentiality, another separate issue, can as well.)
Consider "Reducing TCB size by using untrusted components---small kernels versus virtual-machine monitors" by Hohmuth et al: untrusted L4Linux servers are securely used to fulfill operation dependencies. In this model, I think having the trusted components depend on the untrusted L4Linux servers to provide mappings of data may violate these security requirements.
Thanks, Neal