OSDev.org

What I mean here are simple, "pure" libc functions commonly used in both the kernel and user space, mostly functions in <ctype.h>, <math.h>, most of <string.h> and some <stdio.h> functions like isalpha(3), sin(3), memset(3) and snprintf(3). These functions does not differ from kernel to userland. If in-kernel versions are exported, calling them is not a syscall, instead that would be placed in a page that can be executed from both kernel space and user space and called like a normal library call.

The in-kernel versions would be weak exported as part of userland libc if it is doable. This will reduce memory usage as libc proper contains only userland-specific code, while the kernel carries of those pure libc code.

It's already pretty common for userland shared libraries to share their read-only pages between users, so what you're describing is extending this mechanism to include the kernel. If your target is a system with extremely limited memory, it may be worth the extra effort, but otherwise there's not much to gain.

It also opens your kernel up to cache side-channel attacks, if you're worried about that sort of thing. (Of course, cache side-channel attacks are also possible between users that share pages.)

Octocontrabass wrote:It's already pretty common for userland shared libraries to share their read-only pages between users, so what you're describing is extending this mechanism to include the kernel. If your target is a system with extremely limited memory, it may be worth the extra effort, but otherwise there's not much to gain.

It also opens your kernel up to cache side-channel attacks, if you're worried about that sort of thing. (Of course, cache side-channel attacks are also possible between users that share pages.)

If I am implementing this, how should I structure the targets? Something like this:

1. Build the cross-shared klibc first as a PIC dynamic library,
2. Build the kernel targeting high half loading and linked against that dynamic klibc,
3. Build a statically linked kernel dynamic linker (kdyld,)
4. Build an early boot stub that prepares and satisfies some basic assumptions and provides basic functionalities for the dynamic linker, for example paging.
5. Build the kernel image by packing the early boot stub, kernel dynamic linker, the kernel itself and klibc in one binary.

Upon boot,

1. the early boot stub starts paging and calls the dynamic linker with information about the packed-in kernel and klibc
2. The kdyld puts klibc and kernel proper into the correct places and edit the pointers appropriately using the paging facility of early boot stub. This serves as the replacement of a higher half kernel's relocation porcess.
3. The kernel starts, reads the data left behind from boot stub and kdyld to prepare its own paging and module loading facility, and frees the memory used by the boot stub and kdyld.

Could you please explain about how the pure libc functions you are talking about require a syscall to begin with?

no92 wrote:Could you please explain about how the pure libc functions you are talking about require a syscall to begin with?

They don't requre a syscall. Instead the booted kernel has them in a location where both kernel-mode and user-mode code can read and execute directly. This way the same piece of code can be used by the kernel, drivers and applications without appearing in multiple locations, saving a lot of memory space.