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 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.)
Home |
Main Index |
Thread Index |
Old Index