--raC6veAxrt5nqIoY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >  =20
> > I have two objections to your proposal above. 1) You're telling other=
=20
> > folks how to spend their time. If someone wants to add this, what reall=
y=20
> > is wrong with it, other than you would have wanted something else? It's=
=20
> > not like we're adding a feature that lets a user gain root privs or=20
> > 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=20
> > adding sysctl interfaces for a program to get data. I believe they are=
=20
> > not. I personally feel quite confident that I can add a sysctl to expos=
e a=20
> > string or int already in the kernel. I am not at all confident I can ad=
d=20
> > 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=
=20
> > fact think it'd be good. I however think we should not tell folks to NO=
T=20
> > add features because they didn't remove kvm groveling.
> >  =20
>=20
> My point is, I don't want to add features that encourage further kvm
> groveling.
>=20
> Here are my major complaints with kvm groveling:
>=20
> 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)
>=20
> 2) it requires these applications to have direct access to kmem, making
> us leave them running at higher privilege then they necessarily need.=20
> (I.e. kvm grovelers *are* a security risk.)
>=20
> 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 wo=
rk.

No one is disagreeing with the above. And also, this thread wasn't about=20
adding NEW kvm grovelers, it was about making it easier to find the booted=
=20
kernel.

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!

> For these reasons, I really, really don't think we should be making it
> any easier to use kvm grovelers at all.  Anyone sophisticated enough to
> be hacking on kvm grovelers *should* be able to figure out how to make
> sysctl work.  If they aren't, then they *probably* shouldn't be hacking
> on kvm grovelers because of point #2 above.

If we were talking about the person writing a new program to grovel, I'd=20
agree with you. 100% actually! But we weren't. We were talking about=20
someone making kernel groveling easier for existing apps.

To be honest, I don't think that's a bad thing. We are still going to want=
=20
to get rid of kernel groveing long-term, as no amount of making life=20
easier will remove issue #2 above.

I guess another reason I don't think making it easier to find the booted=20
kernel would be bad is that I've seen us all-too-often direct features=20
like this, and the net result is that we end up lacking features.

Take care,

Bill

--raC6veAxrt5nqIoY
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFET7V/Wz+3JHUci9cRAgxaAKCCgOuzIFk4OMf5eOZIZTcPpdDdAQCeImpl
PixzpEJ3nNN273SSWOAkP9o=
=flMJ
-----END PGP SIGNATURE-----

--raC6veAxrt5nqIoY--