re: Problem with syscall_disestablish() - PR kern/50430

[matthew green <mrg%eterna.com.au@localhost>]

> >> - filemon(4) is utterly broken.  it literally replaces the sysent
> >>   values for the current emulation while active.  so it has an ugly
> >>   obvious problem with runtime usage (particularly at unload.)
> >>   however, a much bigger problem is that it adjusts an emulation
> >>   that might not be the default one.  (32 bit modload of filemon
> >>   on a 64 bit kernel, i think, will adjust the netbsd32 sysent.)
> >>   so it could break the emulation.  this also means that every
> >>   other emulation will not be affected and IO will be missed (see:
> >>   "utterly broken".)
> >
> > I think this is worth being a separate PR.
> >
> > (My original question was about
> > syscall_establish(9)/syscall_disestablish(9).  Now I believe these are
> > OK; but their users doing bad things is a different story.)
> 
> Well, filemon(4) doesn't even use syscall_{,dis}establish().  It just
> manipulates the sysent[] table directly.
> 
> In any case, I've gone through filemon in some detail, and I think
> I've fixed all of the really bad things.  It should be safe to use,
> although the only real use-case that anyone can identify is make(1).

i don't think that filemon(4) is done properly or at the right
layers.  it should hook directly into the vfs layer itself, not
hijack system calls.  it certainly still doesn't work properly
for netbds32 binaries or any other binaries.

your changes are helpful, but it's still very very broken.


.mrg.