YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>
>>> for long term, i want to remove "lookup before create" from vfs.
>>> so i hope to see the assumption is removed from veriexec, rather than
>>> making the rest of kernel veriexec-aware.
>> So it's not just an *NFS* optimization, is it? :)
> 
> probably, but it's merely my thought at this point.

Okay. I gave this some thought. First, I think we need to better define
the interaction between NFS (and probably remote file-systems in
general) and Veriexec. IIRC, we did this a long time ago, but we
really should make it clear and documented. We're also missing the
per-page fingerprints that make it "easier to trust" files from a system
you have no control over.

That out of the way, it seems that this problem only applies to remote
file-systems, even if the "create" semantics are changed. Correct me if
I'm wrong, but the local file-system implementation will always know
when it's going to create a file or just open it -- even if the VFS
layer issues a "create if doesn't exist". Presuming that's the case,
wouldn't it be possible to add a kauth(9) scope allowing subsystems like
Veriexec to listen to, potentially blocking events?

If that's possible, then the problem occurs only when we can't receive
(and react) to such events, as is the case with remote file-systems. For
that reason, my vote would be to, at least for now, #ifdef it in the NFS
code.

-e.