Subject: Re: Getting rid of /dev/veriexec
To: Elad Efrat <elad@NetBSD.org>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 12/02/2005 07:44:47
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
>> are a much better way of doing this type of request/response
>> operation. But we don't have Mach messaging, so we overloaded
> Until we have Mach messages we have two options: keep programs that
> read arbitrary kernel memory, or use a temporary solution (that is
> 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