On Dec 2, 2005, at 7:37 AM, Elad Efrat wrote:

> Jason Thorpe wrote:
>
>> I don't really like how we overload sysctl in this way.  Mach   
>> messages
>> are a much better way of doing this type of request/response
>> operation.  But we don't have Mach messaging, so we overloaded  
>> sysctl.
>
> Until we have Mach messages we have two options: keep programs that  
> can
> read arbitrary kernel memory, or use a temporary solution (that is  
> also
> centralized and clean, for when we need to change it).

Ok, this discussion has gone off onto an unfortunate tangent.  Let's  
just be clear here:

WE ORIGINALLY STARTED TALKING ABOUT MAKING VERIEXEC USE SYSCTL.   
VERIEXEC DOES NOT CURRENTLY USE KMEM.  Therefore, there is no  
argument to be made in favor of making veriexec use sysctl in lieu of  
kmem, because it does not currently do so.

Yes, I ALSO said that I don't particularly like the fact that sysctl  
is used for things that kmem used to be used for... but at NO TIME  
did I say that I liked kmem-groveling BETTER.

> Even if this is all temporary, I prefer the sysctl route over the
> device/kmem route anytime.

As you said before, there is really no change to veriexec here except  
for "sysctl entry point vs device entry point".  Since both choices  
are basically non-optimal, I don't see any real benefit to changing  
veriexec at this time, since you're just trading one ugly solution  
for another.

-- thorpej