Subject: Re: @booted_kernel magic symlink?
To: Bill Studenmund <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 04/26/2006 11:53:56
Bill Studenmund wrote:
> On Wed, Apr 26, 2006 at 10:30:04AM -0700, Garrett D'Amore wrote:
>> Bill Studenmund wrote:
>>> On Tue, Apr 25, 2006 at 04:32:11PM -0700, Garrett D'Amore wrote:
>>> I have two objections to your proposal above. 1) You're telling other
>>> folks how to spend their time. If someone wants to add this, what really
>>> is wrong with it, other than you would have wanted something else? It's
>>> not like we're adding a feature that lets a user gain root privs or
>>> something silly like that; I fail to see how it will really hurt.
>>> 2) You're assuming that adding a sysctl to get a string is as hard/easy as
>>> adding sysctl interfaces for a program to get data. I believe they are
>>> not. I personally feel quite confident that I can add a sysctl to expose a
>>> string or int already in the kernel. I am not at all confident I can add
>>> the data marshaling needed to replace a kvm groveler.
>>> I'm not disagreeing that it'd be nice to get rid of kvm-groveling, I in
>>> fact think it'd be good. I however think we should not tell folks to NOT
>>> add features because they didn't remove kvm groveling.
>> My point is, I don't want to add features that encourage further kvm
>> Here are my major complaints with kvm groveling:
>> 1) the obvious problem of finding a matching kernel -- if you don't boot
>> from a kernel stored in the root filesystem (and even then, the problem
>> this kind of solution is trying to solve to determine *which* file)
>> 2) it requires these applications to have direct access to kmem, making
>> us leave them running at higher privilege then they necessarily need.
>> (I.e. kvm grovelers *are* a security risk.)
>> 3) some systems don't have a kernel in the root filesystem at all. e.g.
>> embedded systems with an "md" root filesystem. kvm grovelers either
>> don't work, or you wind up having to waste a *lot* of memory keeping
>> another copy of your kernel around in the md root in order to let them work.
> No one is disagreeing with the above. And also, this thread wasn't about
> adding NEW kvm grovelers, it was about making it easier to find the booted
> The irritating thing about your complaint is that the initial point of the
> thread was to try and address your complaints (1) and (3). :-) It doesn't
> seem fair to use complaints about something as reasons to NOT address
> those very complaints!
This does nothing for complaint number 3. (Unless you also have a
kernel in a *filesystem* somewhere. Which it might well not be. E.g.
for a compact embedded system you don't want to duplicate the kernel
anywhere, and it might be on a device that doesn't have a mountable
filesystem on it.) And by resolving complaint number 1, it reduces the
likelihood that anyone will spend time working on complaints number 2 and 3.
> I guess another reason I don't think making it easier to find the booted
> kernel would be bad is that I've seen us all-too-often direct features
> like this, and the net result is that we end up lacking features.
See, I see it another way, which is that by not taking the time to DTRT,
we band-aid ourselves into a corner where problems #2 and #3 never get
fixed, because "most users" with laptops and local disks can live with
it that way. (Of course, if they just work around this by making sure
/netbsd is a copy of their booted kernel, then it *also* works now.)
If I had a little more time, I'd go ahead and try to fix the kernel
grovelers myself. I don't know how many of them are out there, but
there aren't many.
Does adding this feature actually really solve a major problem? I doubt
it. Anyway, if the group feels its important to band-aid this
half-solution to one-third of the problem, then I will STFU now.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191