tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



On Sun, 22 Nov 2015, Masao Uebayashi wrote:

On Wed, Nov 18, 2015 at 3:18 PM, matthew green <mrg%eterna.com.au@localhost> wrote:
there's a fairly significant problem with this implementation.

you're only catching callers who use end up going through sy_call()
and that's not the majority.  mostly they're called directly from
MD code.  so to fix that, you have to update every platform syscall
handler.

FWIW, I did check the archives from 8 years ago when ad@ added the
sy_call() wrapper.  It appears that he had already addressed the
several md-specific syscall dispatchers to use the wrapper, so it
seems that we don't need to do anything special.  See [1] for the
relevant commit.  If you can point out any other code that still
needs to be updated, please do!

[1]http://mail-index.netbsd.org/source-changes/2008/10/21/msg211565.html

i think you're OK here.  i did happen to find a couple of weird things
just now:

- 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).



+------------------+--------------------------+-------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+------------------+--------------------------+-------------------------+


Home | Main Index | Thread Index | Old Index