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

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

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