On Wed, Nov 18, 2015 at 3:18 PM, matthew green <[email protected]> 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.)
