Re: nfs optimization and veriexec

> 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.

> Basically, Veriexec has a feature where it can prevent
creation of new
> files. I'd like to maintain that feature... or at least
learn more about
> what benefits this optimization has if the direction is
that the two
> can't co-exist.

it reduces the number of rpcs for an operation.

> Would it be possible to have Veriexec treat a
"create unless exists" as
> "create"? or would that break programs that
open, say, log files with
> O_RDWR_CREAT?
> 
> -e.

doesn't "lockdown mode" break such programs by
preventing O_RDWR anyway?
i guess O_RDONLY_CREAT is
rare.

YAMAMOTO Takashi

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.