>From: "Perry E. Metzger" <perry@piermont.com>
>
>And the average modern card with accelerators will likely let you
>touch enough of the rest of memory with commands to the card to
>obviate the entire help that might have given you.

Doing that is going to be much more difficult than just grovelling
around in /dev/mem or /dev/kmem.  It will also be fairly obvious if
someone kills xdm in order to gain access to the aperture driver to
issue commands to the card (remember, it is limited to one
simultaneous open()).

>Look, there's a reason this isn't built in to NetBSD...

Perry, I'm sure there are good reasons why a lot of things aren't
built into NetBSD.  That doesn't mean that there aren't bad reasons
why other things aren't built into NetBSD.  It also doesn't mean that
good or bad reasons for not building something into NetBSD should
never be questioned and discussed.

If I'm correctly following your line of reasoning, NetBSD shouldn't
have securelevels at all, or immutable flags, or any other security
features, because once someone has cracked root, it's possible in one
way or another to circumvent all these things (e.g. by installing a
new kernel compiled with ``options INSECURE'' defined).  Not everyone
agrees with this reasoning.  In some cases, blocking a "casual" attack
on a machine is enough, and making it more obvious that a concerted
attack has occurred is desirable.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.
"Microsoft is _really_ unreliable but Linux is _worse_."  -Ken Thompson