I know system call's uses is to communicate between use-level and kernel-level
So, Does that mean I can write kernel memory with system call?
e.g. write() is used to write kernel memory
But if what I think is available, It also relate big-security problem?
If I can't, why?
Let's break your questions down one by one.
Yes you can write to kernel memory via system calls directly if you implemented one that allowed writing to arbitrary locations in memory. Whether or why you would want something like this is another question. Something like this would pose a huge security risk. For example, any process can elevate their privileges or install rootkits in the kernel easily using your system call.
However, Linux does have an interface for reading and writing to kernel memory. Have a look at /dev/kmem. It allows you to open kernel memory as a 'file', seek around and read and write to it.
Related
I'm trying to research information about how to implement the memory management system in a DBSM. I know the theoretical part, but can't find anything about bypassing the memory management system in Linux, windows nor mac OX.
I'm trying to implement an efficient DBMS myself for fun. Which should be able to run on any common OS. In Database Systems The complete book, they discus the importance on fitting the relations/tables in adjacent sectors/blocks on hardware for faster read/write. But i can't seem to find anything when crawling the web. Is there a way to bypass the memory management system, such that I can write to specific locations on disk in such that the data saved there are placed on continuously blocks and so that the file system can recognize the data as a file?
I know that this is not a general coding question.
I'm used to write in C, C#, F#, ML, Python and a little gnu assembly.
For clarification I do not mean which DBMS should I use, I'm trying to implement the the DBSM myself.
Is there a way to completely free memory in TCL, meaning to reallocate it back to the operating system without closing the tclsh.85 process??
If you're doing this because you're about to unload the tcl DLL from your process, there's the Tcl_Finalize() API call. Otherwise, no, there's no way to do it by default. If you build Tcl with the PURIFY symbol defined (named for a commercial tool that does memory analysis) then Tcl will use the system memory allocator instead of its own high-performance thread-aware allocator; that might be able to release memory back to the OS. Or it might not; it's out of Tcl's hands entirely.
There's no script-level API for this at all. Most of the time, if a process uses a lot of memory it's either going to exit soon, going to reuse that much memory, or can rely on the OS just paging the unused memory out.
Basically I want implement my own semaphore inside the linux kernel and be able to use it in user programs.
I've made some progress implementing the kernel code however I do not know how to make semaphore type and the functions I've written available to user programs.
User programs would need to have access to my semaphore type and its functions (wait, signal, ...)
Is there any way to this so that a linux using a kernel compiled with my code would be able to use my semaphore simply by including a header file?
I'm no pro when it comes to the linux kernel, so if I'm making any obvious mistakes feel free to point them out.Thanks.
The kernel version I'm using is 2.6.32.
I would recommend looking into the user space libraries for how a semaphore implemented for user space programs.
Semaphores are only available in kernels older 2.6.16 kernels, as mutex's appeared after that version of the kernel. Only the previous implementation used semaphores. The newer code should use mutexes instead which are used only in process context. You may want to look the following headers, struct's and api's.
#include <linux/mutex.h>
struct mutex
mutex_{lock,trylock,unlock,lock_interruptable}()
Also you may want to look semaphore.c for the implementation.
i want to access my system resources such as CPU without the use of OS system calls.
is there any way to make this possible?
The only way to access the hardware directly on most modern operating systems, Linux and Windows included, is via kernel code. Linux Device Drivers is an excellent starting point for writing such code on Linux, even if it is a bit dated.
Otherwise, the OS provides various I/O facilities and controls the allocation of resources to the user applications, using the system call interface. The system call interface is omnipresent in its basic concept among all operating systems that actually have some sort of separation between kernel and user code. The use of software interrupts is the standard way to implement system calls on current hardware.
You need a system call to allocate the slightest amount of memory and even to read or write a single character. Not to mention that even a program that does absolutely nothing generally needs a few system calls just to be loaded.
You could gain more direct access to the hardware if you used DOS or an exokernel design.
But why would you want to do that anyway? Modern hardware is far from trivial to work with directly.
I am very curious in messing up with HW. But my top level "messing" so far was linked or inline assembler in C program. If my understanding of CPU and ring mode is right, I cannot directly from user mode app access some low level CPU features, like disabling interrupts, or changing protected mode segments, so I must use system calls to do everything I want.
But, if I am right, drivers can run in ring mode 0. I actually don´t know much about drivers, but this is what I ask for. I just want to know, is learning how to write your own drivers and than call them the way I should go, to do what I wrote?
I know I could write whole new OS (at least to some point), but what I exactly want to do is acessing some low level features of HW from standart windows application. So, is driver the way to go?
Short answer: yes.
Long answer: Managing access to low-level hardware features is exactly the job of the OS kernel and if you only want access to a single feature there's no need to start your own OS from scratch. Most modern OSes, such as WIndows, Linux, or the BSDs, allow you to add code to the kernel through kernel modules.
When writing a kernel module (or device driver), you write code that is going to be executed inside the OS kernel and will thus be running in CPU ring 0. Great power comes with great responsibility, which in this case means that you should really know what you're doing as there will be no pre-configured OS interface to prevent you from doing the wrong things. You should therefore study the manuals of your hardware (e.g., Intel's x86 software developer's manuals, device specs, ...) as well as standard operating systems development literature (where you're also going to find plenty on the web -- OSDev, OSDever, OSR, Linux Device Drivers).
If you want to play with HW write some programs for 16-bit real-mode (or even with your own transition to protected-mode). There you have to deal with ASM, BIOS interrupts, segments, video memory and a lot of other low-level stuff.