Vsyscall everything

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
User avatar
Demindiro
Member
Member
Posts: 96
Joined: Fri Jun 11, 2021 6:02 am
Libera.chat IRC: demindiro
Location: Belgium
Contact:

Vsyscall everything

Post by Demindiro »

I've been thinking about replacing all direct syscalls with dynamic function
calls, much like Linux's vsyscall/vDSO. At first it seemed like a silly idea
but the more I think about the more merit I believe it has.

Brief: what is vsyscall/vDSO

Essentialy, it is a "syscall" in userspace to speed up functions such
as Linux's `clock_gettime`, which can be implemented using either the
HPET, which requires a syscall, or RDTSC, which can be done in userspace.

Using vsyscalls for open(), mmap() et al.

At first sight it doesn't make sense to use vsyscalls for these operations.
They require jumping into kernel space to perform privileged operations
such as sending a command to a disk or modifying the page tables.

However, it can be useful to intercept syscalls: instead of requiring kernel
support the vsyscall table can be modified to point to custom routines.

Allowing syscalls to be intercepted in this manner makes it trivial to
run multiple processes in just a single (from kernel point-of-view) process.
This is useful when running many related processes in parallel.

For example, many compilers launch multiple processes. Each process needs to
allocate memory, open files ... All of these operations can be expensive
due to privilege switches, the kernel needing to zero out pages, etc.

By running these processes as one process a lot of overhead can be avoided:
pages do not be zeroed nor mapped in, files can stay mapped during the entire
compile run such that reading a file simply involves returning a pointer, etc.

(Obviously, this should only be done with processes that trust each other.)

More "syscalls"

Functions that are traditionally part of a library, such as `memcpy()`, can
also be implemented as a vsyscall. By doing this the overhead of linking
a library can be avoided while still having the benefit of dynamic algorithm
selection.

Precedent: svchost

There is some precedent for running multiple processes/services/... in just
a single process. For example, Windows has svchost with the purpose
of reducing resource consumption. There are all the single address space OSes
too, of course.

I'm not aware of any other OS doing anything similar. If you know of any
please do tell me :).
My OS is Norost B (website, Github, sourcehut)
My filesystem is NRFS (Github, sourcehut)
Octocontrabass
Member
Member
Posts: 5568
Joined: Mon Mar 25, 2013 7:01 pm

Re: Vsyscall everything

Post by Octocontrabass »

Demindiro wrote:I've been thinking about replacing all direct syscalls with dynamic function
calls, much like Linux's vsyscall/vDSO.
Or Windows's entire API.
User avatar
Demindiro
Member
Member
Posts: 96
Joined: Fri Jun 11, 2021 6:02 am
Libera.chat IRC: demindiro
Location: Belgium
Contact:

Re: Vsyscall everything

Post by Demindiro »

Octocontrabass wrote:
Demindiro wrote:I've been thinking about replacing all direct syscalls with dynamic function
calls, much like Linux's vsyscall/vDSO.
Or Windows's entire API.
You made me realize it should be possible to do the same thing with any application that relies entirely on dynamic libraries for handling syscalls. I wonder if there is already a Linux program that (ab)uses this for running multiple programs in one process.
My OS is Norost B (website, Github, sourcehut)
My filesystem is NRFS (Github, sourcehut)
Post Reply