Closed llly closed 5 months ago
I don't find a similar one in the issue list of Filesystem code needs to be rewritten. Help me to close this one if it's a know issue.
It's actually a feature :) The original idea behind this caching was that Graphene doesn't share FS state with the host OS. In other words, only Graphene processes are expected to modify the files in mounted directories.
But yes, this feature probably doesn't make sense. @mkow @boryspoplawski @yamahata Should we just remove FS caching inside Graphene and allow the host to modify files? (Of course, SGX Protected Files will still correctly detect modifications by the host, by their design.)
Yes, I think this feature is broken by-design and should be removed. I linked this issue to the list in gramineproject/graphene#1803 (fs rewrite).
1) I like the idea of separation of Graphene and host filesystems and I don't think we can implement some features (like mounting) without it. 2) From what I can see from the logs, this is two in Graphene processes not seeing each others changes to fs, which is definitely an issue we need to address (be it now or when rewriting fs).
Current status:
We don't want to support host modifying files without Graphene knowing, but we definitely do want to support multiple processes modifying files. This likely requires synchronizing information using IPC (at the very least, sending information that cache needs to be invalidated for some process).
I did some early attempts ("sync engine", gramineproject/graphene#2158) but I feel that the solution needs to be rethought and simplified before going forward.
Description of the problem
shim_do_stat()
,shim_do_lstat()
etc. check dentry cache for filesystem first. If the file is already looked up and exists in dentry cache, these function return the cached data. However the cache will be out of sync after other programs modify it. Then program in Graphene can get conflict result when callingopen()
to access real file.Steps to reproduce
A scenario that a program stat() a file, exec
rm
program of OS to delete it, stat() the file again to conform thatrm
works.Expected results
The second stat() return ENOENT.
Actual results
The second stat() return 0 and cached stat.
Additional information
Here is the related log of the scenario.