0

How does the operating system manage the program permissions? If you are writing a low-level program without using any system calls, directly controlling the processor, then how does an operating system put stakes if the program directly controls the processor?

Edit

It seems that my question is not very clear, I apologize, I can not speak English well and I use the translator. Anyway, what I wonder is how an operating system manages the permissions of the programs (for example the root user etc ...). If a program is written to really low-level without making system calls, then can it have full access to the processor? If you want to say that it can do everything you want and as a result the various users / permissions that the operating system does not have much importance. However, from the first answer I received I read that you can not make useful programs that work without system calls, so a program can not interact directly with a hardware (I mean how the bios interacts with the hardware for example)?

Chi non salta Pavarotti è
  • 37
  • 7

2 Answers2

1

1) It is imposible to have a program that that does not make any system calls.

2) Instructions that control the operation of the processor must be executed in kernel mode.

3) The only way to get into kernel mode is through an exception (including system calls). By controlling how exceptions are handled, the operating system prevents malicious access.

If a program is written to really low-level without making system calls, then can it have full access to the processor?

On a modern system this is impossible. A system call is going to be made in the background whether you like it or not.

user3344003
  • 20,574
  • 3
  • 26
  • 62
  • 1) not quite true. You could just segfault or run an illegal instruction and have the OS kill your process. You can't make a *useful* process with no system calls, though. – Peter Cordes Sep 12 '18 at 20:26
  • 2) this is pretty vague. All instructions "control the operation of the processor" while they're executing. It sounds like the OP might be asking how pre-emptive multitasking works to interrupt native code that doesn't make any system calls in a long-running loop. But the question is too unclear, so your interpretation is a reasonable guess, too. – Peter Cordes Sep 12 '18 at 20:28
  • @PeterCordes I apologize if my question was not clear enough, I modified it. – Chi non salta Pavarotti è Sep 12 '18 at 21:08
  • A process cannot start up without making system call. Creating the address space requires a system call. – user3344003 Sep 12 '18 at 23:56
  • The system call that starts a process is made by its parent, *not* by the process itself. (And you+OP said program, so I was talking about the code that starts after a POSIX `execve` to start a new program in a process, not about `fork()` to create a new process that's a copy of the parent. Windows has a system call that creates a new process running a specified `.exe`, so there isn't a distinction there.) – Peter Cordes Sep 13 '18 at 00:05
  • You can trivially make a Linux static executable that crashes without making any system calls by assembling an empty file with `nasm`, and linking it into a static executable. Run it with `strace ./a.out` and all you'll see is the parent's `execve` and then a segfault. – Peter Cordes Sep 13 '18 at 00:06
1

Depends on the OS. Something like MS-DOS that is barely an OS and doesn't stop a program from taking over the whole machine essentially lets programs run with kernel privilege.

An any OS with memory-protection that tries to keep separate processes from stepping on each other, the kernel doesn't allow user-space processes to talk directly to I/O hardware.

A privileged user-space process might be allowed to memory-map video RAM and/or I/O registers of a device into its own address space, and basically act like a device driver. (e.g. an X server under Linux.)

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847