Re: permissive vs. restrictive issue and solutions...

sarnoldat_private

On Fri, Jun 01, 2001 at 02:37:32PM -0400, jmjonesat_private wrote:
> I know I'm going to get into trouble here, but ... doesn't that
> presume that all the changes are going to be the same?  You're
> engineering other people's projects that way.

Yes. It does presume that all serious security modules are going to want
a minimum of traditional Unix security checks. And if, at some point in
the future, it is discovered that the traditional Unix security checks
are missing somewhere, everyone will be forced to update their modules.

I'm hoping the chaining mechanism, together with posix capabilities,
will be sufficient for nearly everyone to avoid reduplicating the Unix
checks.[1]

> I don't either, except if the value of "err" is possibly ignored some 
> places it's a waste of time to precalculate it.

The checks in place to compute "err" are likely less than the checks to
be implemented for everything else. It makes sense to include it (if #3
is the option we choose) on the off-chance that its answer could speed
up the answer returned by the module by allowing the module to avoid
computing its own answer.

> You know, some weeks ago we argued about the (nominal) impact of an 
> call-possibly-to-donothing vs. a check-and-call in modern architectures.
> Now we're arguing if we should do actual decisionmaking that's not 
> necessarily needed or not.  I see a parallel, somehow.  We elected to
> call-the-possibly-dothing to save a few measly fractional CPU clocks!   
> Is a whole decision-making tree less costly?

Well, it depends. Note this is largely conjecture based on my own
understanding of modern CPUs -- benchmarking is of course the best way
to discover the answer, but .. that takes a lot more work. :)

With speculative execution, CPUs will either pay very little or very
high cost for 'if' statements, depending upon its guess. I assume it
guesses incorrectly every time, mainly since it is easier to reason
with. So, I try to remove 'if' statements where possible. A check such
as (if ops->function) ops->function() will run slower than:
void ops.function(void) { return; }
ops->function()

In this case, computing the checks is (quite probably) faster than using
the result. So, a module function that does something like this:

int module.permission_foo(int kernel_suggests, ...) {
	/* compute answer on other arguments */
	return our_own_answer;
}

-- never using the kernel_suggests parameter -- won't pay much for the
kernel's suggestion, which is probably often very easy to compute
compared to the cost of a botched speculative branch execution.

I don't think the added cost of the kernel computing its own suggestion
is much of a reason to discount option #3.

(And yes, I am basing this in large part on my experiences with
unrolling loops; in some cases, the execution speed of my software was
linear with respect to the number of 'if' statements, not really
noticable with the other instructions I was running. :)

[1]: I'm hoping, that since Caldera bought SCO a little while ago, no
one will sue me for using the phrase "Unix security checks" when
referring to the Linux kernel. If Caldera intends to keep Unix and Linux
seperate (fair enough, they paid the money for Unix[tm]), could someone
let me know before I get sued? Thanks. :)

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module