1

I'm trying to understand operating system internals, but I'm having a bit of a problem. I'm wondering how operating systems give out virtual memory, assert that programs are not writing in and out of bounds (this would require some sort of validation by the operating system for each instruction that will be run, which seems odd), and manage/handle system calls.

In addition, I'm trying to find the difference between a boot executable that contains assembly code and a regular executable containing assembly instructions on a UNIX operating system. They obviously have different permissions, but to what degree, and how does it's memory layout differ? It seems that a regular assembly program would have a .bss, a .data, .text, etc.

To summarize:

How does an operating system set up an environment for an assembly program to run? How does it differ to an assembly program that is not running on an OS, but are direct instructions to the CPU?

Thanks!

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Sammy Hajhamid
  • 43
  • 7
  • Permissions are an OS-level concept. A bootloader doesn't have permissions, it's just loaded by the firmware (according to BIOS or UEFI standards, on a normal x86 PC). A program that runs under Linux isn't special just because it was hand-written in assembly instead of GCC generating assembly for you. Either way it's just machine code in an ELF executable. – Peter Cordes Aug 21 '19 at 05:57
  • Either way the CPU runs the machine code directly. On bare metal you're normally running in "kernel" mode, real mode or ring 0 of protected mode. vs. under an OS usually in ring 3 (CPL=3), where privileged instructions like `hlt` or `rdmsr` will fault. It's still the CPU reading the machine code directly, though. – Peter Cordes Aug 21 '19 at 06:00
  • Related: [Why does GCC not assign the static variable when it is initialized to 0](//stackoverflow.com/q/57543880) covers a lot of detail in how Linux creates a process from ELF program headers. – Peter Cordes Aug 21 '19 at 06:03
  • Changed my mind, this isn't really a duplicate of [Is an operating system kernel an interpeter for all other programs?](//stackoverflow.com/q/39441950) and [How is a process created from an ELF file?](//stackoverflow.com/q/38842557). I guess a useful answer could describe what UEFI or BIOS gives you vs. ELF program headers for the OS's program-loader. Also related: [How to run a program without an operating system?](//stackoverflow.com/q/22054578) OTOH, I think it's arguably too broad, so maybe should stay closed. If anyone wants to write up an answer, let me know and we can reopen. – Peter Cordes Aug 21 '19 at 06:09
  • 1
    the key is having an mmu, without an mmu you cant really limit the address space. with an mmu designed for use with an operating system you can make it so every program thinks it is living in say a zero based address space even though the physical is somewhere else and possibly fragmented. when that application goes out of its allocated space, the mmu generates a fault for the kernel to handle where it is determined what to do for the application. for running virtual machines you may intentionally fault accessing virtual peripherals then handle the emulation in the kernel. – old_timer Aug 21 '19 at 15:20

0 Answers0