0

Can process execute new program without the kernel knowing? Usually, when the program is executing kernel gives to it its own process after receiving the syscall (such as exec() or fork()). In this case, everything goes through the kernel, which finally starts the program with, for example, ELF handler. In practice, of course, when running a new program, you want a separate process for it, but what if it's not necessary? Can a program/process xhathat transfer (if it doesn't already have it) a executable binary from the file system (yes, with syscalls) to its own virtual memory area and start executing it inside its process? In that case, the kernel would still only know that the program/process xhathat is doing something, but it wouldn't separately know this program executed by xhathat?


As to "without the kernel knowing"....what does that mean??

What I mean by that is that the kernel doesn't actually "start/execute the program" (when normally the kernel _always_ does that, whether it's a binary or an interpreted script containing the shebang), only indirectly. Yes, it loads a new program from mass storage into the memory area of ​​this xhathat process, but does not start/execute it and is not aware of its start/execute. It doesn't do exec(), fork(), etc. kernel system calls for various starts/executions. When the kernel doesn't consciously launch a program, the program also doesn't show up among processes, for example (because it's just a "process/execution" inside the xhathat process). Can you catch up? As far as I can see, this is also possible with binary compiled programs (and of course also interpreted programs). This only came to mind when I realized that bash or systemd or whatever that "starts/execute" the programs/process, normally the kernel actually does the start/execute (even shebang scripts, as I stated earlier). However, after learning this, I had to wonder if it always has to be this way? I take your answer that it need not be so; although of course it is usually better to do that (that the kernel starts all programs/processes) and that is what is done.

By the way, What all (simply put) kernel is needed to do what I'm describing? The only thing I came up with was downloading this new program from the mass storage, but what if the program was already in the central memory and it didn't need to be downloaded from the mass storage separately? Could the process just directly start executing a new program/"process" without any interaction with the kernel?

3
  • Just wondering, is there a specific use case in mind, or is it just a general knowledge question out of curiosity?
    – aviro
    Nov 29, 2022 at 9:29
  • Mostly curiosity that helps to better understand some things.
    – user551100
    Nov 29, 2022 at 14:20
  • what does "xhathat" mean?
    – ilkkachu
    Nov 30, 2022 at 8:50

2 Answers 2

2

Yes, this is possible. The already-running process needs to load (or map) the new program at the appropriate locations in the process’ virtual address space, load the dynamic loader if necessary, set up the required data structures on the stack, and jump to the new program’s entry point in memory. (Many of these operations involve the kernel, but nothing specific to loading a new program.)

Processes can’t create entirely new address spaces without fork-style help from the kernel, but that’s typically not much of a problem because the initiating program shouldn’t expect to regain control after the new program runs, and therefore it doesn’t matter that the two programs share their address space.

See the grugq’s Design and Implementation of Userland Exec for a more detailed explanation.

1

Yes and no...

So, trivially, many program languages are interpreted. So if, say, your first program is a python program running in a python interpreter, it would be trivial to just import another file and start running that.

It's only a little bit harder to do the same thing with a binary program rather than an interpreted program.

As to "without the kernel knowing"....what does that mean?? Where did the second program come from? Did you load it from disk? (The kernel does that for you...) Did you load it from the network? (The kernel does that too.) And if you want to replace executable pages, modern kernels for the most part don't allow pages with executable code to be written, or writable pages to contain code that will be executed, so to update native machine code pages rather than just interpreting something new, the kernel would have to be involved in loading those pages and making them executable.

A process can't start another process without the kernel's direct involvement. It might be able to replace itself or add more executable code to itself without a lot of kernel involvement, but you can't escape needing to do some kind of I/O to get those pages.

The kernel "knows" about the running process because:

  • It knows what pages in memory are executable for the process as part of the page table permissions. This can't be easily bypassed.
  • It (usually) knows what file those executable pages came from, because they are mapped into memory and demand paged, meaning the kernel loads the pages from the files on disk into memory on demand. Even if the pages were already cached in memory, this still happens as part of the page cache system.
  • The kernel knows the name used to start the initial executable.
  • The kernel knows the command line and environment the process was started with -- although the process can edit this on most systems
  • The kernel knows what files have been opened and red from.

Most of the above can be displayed with the ps command on all unix systems. All of the above is available in /proc/ on linux systems (except maybe page table info).

So can it be done without exec()? Sure! Can it be done without involving the kernel in some way? Not really.

2
  • Hi, thanks for the answer. Would you still have time to answer the new questions in the my post (above)?
    – user551100
    Nov 29, 2022 at 14:25
  • Most of that is already answered.
    – user10489
    Nov 30, 2022 at 5:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .