Page MenuHomeFreeBSD

syscall: Allow the sv_fetch_syscall_args to return an uninitialized sysent on error
AbandonedPublic

Authored by dchagin on Sep 14 2023, 11:02 AM.
Referenced Files
Unknown Object (File)
Sun, Apr 21, 1:47 AM
Unknown Object (File)
Tue, Apr 16, 3:43 AM
Unknown Object (File)
Wed, Apr 10, 6:02 AM
Unknown Object (File)
Feb 4 2024, 5:53 AM
Unknown Object (File)
Dec 12 2023, 2:20 AM
Unknown Object (File)
Nov 6 2023, 7:20 PM
Unknown Object (File)
Oct 28 2023, 12:17 AM
Unknown Object (File)
Oct 24 2023, 9:41 AM
Subscribers

Details

Reviewers
kib
Summary

To avoid magic handling of non-existing system calls the ABI
sv_fetch_syscall_args() can simply return ENOSYS.
This will be used in the following Linux emulation layer changes.

MFC after: 1 week

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 53585
Build 50476: arc lint + arc unit

Event Timeline

dchagin added a reviewer: kib.
dchagin added a project: Linux Emulation.

Can you explain more? Does linuxolator need syscall slot 0?

In D41859#954114, @kib wrote:

Can you explain more? Does linuxolator need syscall slot 0?

I want to deorbit linux_nosys hack from syscalls.master and fix sv_fetch_syscall_args: https://reviews.freebsd.org/D41902 & https://reviews.freebsd.org/D41901
Due to native nosys() kills binary we use linux_nosys hack

D41901 sounds as a hack, again.

Am I right that the issue is that nosys() sends signal, while Linux' nosys should not? If yes, there are two options:

  1. add sysentvec flag to disallow sending signal
  2. add sv_nosys method and call it from nosys() instead of direct tdsignal()
In D41859#955044, @kib wrote:

D41901 sounds as a hack, again.

Am I right that the issue is that nosys() sends signal, while Linux' nosys should not? If yes, there are two options:

yes

  1. add sysentvec flag to disallow sending signal
  2. add sv_nosys method and call it from nosys() instead of direct tdsignal()

This way is so generic while for Linuxulator we just need to return ENOSYS. I updated D41901, now callp is initialized and fetch_syscall_args() returns ENOSYS for non-existent syscall. What do you think?

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Ah, this revision is not needed for D41901 now

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

In D41859#955376, @kib wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

yes, OBSOL syscalls, https://people.freebsd.org/~dchagin/nosys.c

In D41859#955376, @kib wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

yes, OBSOL syscalls, https://people.freebsd.org/~dchagin/nosys.c

And ABSENT as well?

I want to have the obsol() handling to be centralized, we need to have single place where the ENOSYS actions like psignal/log/uprintf happen, and it seems that it cannot be easily kept in nosysl(). Perhaps nosys() should become just return (ENOSYS); and dedicated code in syscallret() do the ENOSYS handling.

In D41859#955406, @kib wrote:
In D41859#955376, @kib wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

yes, OBSOL syscalls, https://people.freebsd.org/~dchagin/nosys.c

And ABSENT as well?

Yes, all SY_THR_ABSENT marked syscalls go throught syscall_thread_enter() which can return ENOSYS then sy_call() is skiped.

I want to have the obsol() handling to be centralized, we need to have single place where the ENOSYS actions like psignal/log/uprintf happen, and it seems that it cannot be easily kept in nosysl(). Perhaps nosys() should become just return (ENOSYS); and dedicated code in syscallret() do the ENOSYS handling.

I understand, however this requires one extra check on a "fast path", may be add a check to a slow path? Like in https://reviews.freebsd.org/D41929