What stops an assembly program from crashing the operating system?Assembly Language Program DesignVerilog asynchronous reads of regs - and design questionUnderstanding timersAVR microcontrollers, who initilizes assembly `data` segment and what is the purpose to have this directive?Microcontroller memory write cyclesProper way of storing a register address on ARM Cortex M4?Is it Possible to Design an Entire Operating System or App using ASIC Chips?Q: Digital potentiometer MCP4162What prevents the construction of a CPU with all necessary memory represented in registers?ARM assembly- cannot use imported value from C++ program

Vocabulary for giving just numbers, not a full answer

How do we create new idioms and use them in a novel?

Create chunks from an array

What is Earthy controling in the ISS cupola?

Why does cron require MTA for logging?

Why do phishing e-mails use faked e-mail addresses instead of the real one?

Can one live in the U.S. and not use a credit card?

When a wind turbine does not produce enough electricity how does the power company compensate for the loss?

What can I do if someone tampers with my SSH public key?

For which categories of spectra is there an explicit description of the fibrant objects via lifting properties?

Is it safe to abruptly remove Arduino power?

Haman going to the second feast dirty

Power Strip for Europe

How can I manipulate the output of Information?

What's the 'present simple' form of the word "нашла́" in 3rd person singular female?

Is it possible that a question has only two answers?

Did Amazon pay $0 in taxes last year?

Shifting between bemols (flats) and diesis (sharps)in the key signature

What is better: yes / no radio, or simple checkbox?

Why couldn't the separatists legally leave the Republic?

Can I negotiate a patent idea for a raise, under French law?

From an axiomatic set theoric approach why can we take uncountable unions?

How to check whether module is loaded with custom configurations?

Recommendation letter by significant other if you worked with them professionally?



What stops an assembly program from crashing the operating system?


Assembly Language Program DesignVerilog asynchronous reads of regs - and design questionUnderstanding timersAVR microcontrollers, who initilizes assembly `data` segment and what is the purpose to have this directive?Microcontroller memory write cyclesProper way of storing a register address on ARM Cortex M4?Is it Possible to Design an Entire Operating System or App using ASIC Chips?Q: Digital potentiometer MCP4162What prevents the construction of a CPU with all necessary memory represented in registers?ARM assembly- cannot use imported value from C++ program













1












$begingroup$


First of all, I am a beginner, so if this question sounds silly, please point out the incorrect assumptions.



From what I understand, the job of an operating system is to manage hardware, and the software that runs on the OS. Also, from what I understand, assembly programs allows one to control hardware almost directly. In an assembly program, one can read and write data into registers, and read and write data into RAM.



Given this freedom to mess with registers and RAM, would it not be possible for assembly programs to affect the operating system? Suppose the OS is using register A to store crucial information. Suppose I write an assembly program, assemble the program, and run the assembled program on the OS. If the program successfully writes junk into register A, the OS will surely be affected.



Questions:



  1. Is it possible to mess with register A in the manner described above?


  2. If not, what stops assembly programs from modifying the registers used by the OS?










share|improve this question











$endgroup$







  • 1




    $begingroup$
    smart programmers...
    $endgroup$
    – Sunnyskyguy EE75
    1 hour ago










  • $begingroup$
    There are a lot of computer architectures now and were in the past, as well as many operation systems were developed. What architecture/OS are you referring exactly? On some (old) architectures there were no possibility to stop program from what it was doing after start, that's correct. But modern hardware/OS have built in hardware tools which give only the part of the memory for the program in "normal" mode (not superuser), and it can't access memory outside this limit. Registers are free to use, as OS don't store any useful info in registers, just in memory/on disk.
    $endgroup$
    – cyclone125
    1 hour ago











  • $begingroup$
    In a microprocessor your program runs in "user mode", the operating systems runs in "system mode." If a user mode program executed a halt instruction, for example, the machine would not halt. The halt would be trapped and the operating system invoked. Regarding RAM, the OS would set up an environment for the user mode program so that, via memory management hardware, what the user program sees as RAM address X would not really be RAM address X.
    $endgroup$
    – George White
    1 hour ago











  • $begingroup$
    @cyclone125 I am not referring to any architecture/OS in particular. It's just a general question.
    $endgroup$
    – Flux
    1 hour ago






  • 1




    $begingroup$
    ... Long ago I used to write in raw machine code. Yee ha !!! :-)
    $endgroup$
    – Russell McMahon
    1 hour ago















1












$begingroup$


First of all, I am a beginner, so if this question sounds silly, please point out the incorrect assumptions.



From what I understand, the job of an operating system is to manage hardware, and the software that runs on the OS. Also, from what I understand, assembly programs allows one to control hardware almost directly. In an assembly program, one can read and write data into registers, and read and write data into RAM.



Given this freedom to mess with registers and RAM, would it not be possible for assembly programs to affect the operating system? Suppose the OS is using register A to store crucial information. Suppose I write an assembly program, assemble the program, and run the assembled program on the OS. If the program successfully writes junk into register A, the OS will surely be affected.



Questions:



  1. Is it possible to mess with register A in the manner described above?


  2. If not, what stops assembly programs from modifying the registers used by the OS?










share|improve this question











$endgroup$







  • 1




    $begingroup$
    smart programmers...
    $endgroup$
    – Sunnyskyguy EE75
    1 hour ago










  • $begingroup$
    There are a lot of computer architectures now and were in the past, as well as many operation systems were developed. What architecture/OS are you referring exactly? On some (old) architectures there were no possibility to stop program from what it was doing after start, that's correct. But modern hardware/OS have built in hardware tools which give only the part of the memory for the program in "normal" mode (not superuser), and it can't access memory outside this limit. Registers are free to use, as OS don't store any useful info in registers, just in memory/on disk.
    $endgroup$
    – cyclone125
    1 hour ago











  • $begingroup$
    In a microprocessor your program runs in "user mode", the operating systems runs in "system mode." If a user mode program executed a halt instruction, for example, the machine would not halt. The halt would be trapped and the operating system invoked. Regarding RAM, the OS would set up an environment for the user mode program so that, via memory management hardware, what the user program sees as RAM address X would not really be RAM address X.
    $endgroup$
    – George White
    1 hour ago











  • $begingroup$
    @cyclone125 I am not referring to any architecture/OS in particular. It's just a general question.
    $endgroup$
    – Flux
    1 hour ago






  • 1




    $begingroup$
    ... Long ago I used to write in raw machine code. Yee ha !!! :-)
    $endgroup$
    – Russell McMahon
    1 hour ago













1












1








1





$begingroup$


First of all, I am a beginner, so if this question sounds silly, please point out the incorrect assumptions.



From what I understand, the job of an operating system is to manage hardware, and the software that runs on the OS. Also, from what I understand, assembly programs allows one to control hardware almost directly. In an assembly program, one can read and write data into registers, and read and write data into RAM.



Given this freedom to mess with registers and RAM, would it not be possible for assembly programs to affect the operating system? Suppose the OS is using register A to store crucial information. Suppose I write an assembly program, assemble the program, and run the assembled program on the OS. If the program successfully writes junk into register A, the OS will surely be affected.



Questions:



  1. Is it possible to mess with register A in the manner described above?


  2. If not, what stops assembly programs from modifying the registers used by the OS?










share|improve this question











$endgroup$




First of all, I am a beginner, so if this question sounds silly, please point out the incorrect assumptions.



From what I understand, the job of an operating system is to manage hardware, and the software that runs on the OS. Also, from what I understand, assembly programs allows one to control hardware almost directly. In an assembly program, one can read and write data into registers, and read and write data into RAM.



Given this freedom to mess with registers and RAM, would it not be possible for assembly programs to affect the operating system? Suppose the OS is using register A to store crucial information. Suppose I write an assembly program, assemble the program, and run the assembled program on the OS. If the program successfully writes junk into register A, the OS will surely be affected.



Questions:



  1. Is it possible to mess with register A in the manner described above?


  2. If not, what stops assembly programs from modifying the registers used by the OS?







assembly register operating-system






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 1 hour ago







Flux

















asked 1 hour ago









FluxFlux

1145




1145







  • 1




    $begingroup$
    smart programmers...
    $endgroup$
    – Sunnyskyguy EE75
    1 hour ago










  • $begingroup$
    There are a lot of computer architectures now and were in the past, as well as many operation systems were developed. What architecture/OS are you referring exactly? On some (old) architectures there were no possibility to stop program from what it was doing after start, that's correct. But modern hardware/OS have built in hardware tools which give only the part of the memory for the program in "normal" mode (not superuser), and it can't access memory outside this limit. Registers are free to use, as OS don't store any useful info in registers, just in memory/on disk.
    $endgroup$
    – cyclone125
    1 hour ago











  • $begingroup$
    In a microprocessor your program runs in "user mode", the operating systems runs in "system mode." If a user mode program executed a halt instruction, for example, the machine would not halt. The halt would be trapped and the operating system invoked. Regarding RAM, the OS would set up an environment for the user mode program so that, via memory management hardware, what the user program sees as RAM address X would not really be RAM address X.
    $endgroup$
    – George White
    1 hour ago











  • $begingroup$
    @cyclone125 I am not referring to any architecture/OS in particular. It's just a general question.
    $endgroup$
    – Flux
    1 hour ago






  • 1




    $begingroup$
    ... Long ago I used to write in raw machine code. Yee ha !!! :-)
    $endgroup$
    – Russell McMahon
    1 hour ago












  • 1




    $begingroup$
    smart programmers...
    $endgroup$
    – Sunnyskyguy EE75
    1 hour ago










  • $begingroup$
    There are a lot of computer architectures now and were in the past, as well as many operation systems were developed. What architecture/OS are you referring exactly? On some (old) architectures there were no possibility to stop program from what it was doing after start, that's correct. But modern hardware/OS have built in hardware tools which give only the part of the memory for the program in "normal" mode (not superuser), and it can't access memory outside this limit. Registers are free to use, as OS don't store any useful info in registers, just in memory/on disk.
    $endgroup$
    – cyclone125
    1 hour ago











  • $begingroup$
    In a microprocessor your program runs in "user mode", the operating systems runs in "system mode." If a user mode program executed a halt instruction, for example, the machine would not halt. The halt would be trapped and the operating system invoked. Regarding RAM, the OS would set up an environment for the user mode program so that, via memory management hardware, what the user program sees as RAM address X would not really be RAM address X.
    $endgroup$
    – George White
    1 hour ago











  • $begingroup$
    @cyclone125 I am not referring to any architecture/OS in particular. It's just a general question.
    $endgroup$
    – Flux
    1 hour ago






  • 1




    $begingroup$
    ... Long ago I used to write in raw machine code. Yee ha !!! :-)
    $endgroup$
    – Russell McMahon
    1 hour ago







1




1




$begingroup$
smart programmers...
$endgroup$
– Sunnyskyguy EE75
1 hour ago




$begingroup$
smart programmers...
$endgroup$
– Sunnyskyguy EE75
1 hour ago












$begingroup$
There are a lot of computer architectures now and were in the past, as well as many operation systems were developed. What architecture/OS are you referring exactly? On some (old) architectures there were no possibility to stop program from what it was doing after start, that's correct. But modern hardware/OS have built in hardware tools which give only the part of the memory for the program in "normal" mode (not superuser), and it can't access memory outside this limit. Registers are free to use, as OS don't store any useful info in registers, just in memory/on disk.
$endgroup$
– cyclone125
1 hour ago





$begingroup$
There are a lot of computer architectures now and were in the past, as well as many operation systems were developed. What architecture/OS are you referring exactly? On some (old) architectures there were no possibility to stop program from what it was doing after start, that's correct. But modern hardware/OS have built in hardware tools which give only the part of the memory for the program in "normal" mode (not superuser), and it can't access memory outside this limit. Registers are free to use, as OS don't store any useful info in registers, just in memory/on disk.
$endgroup$
– cyclone125
1 hour ago













$begingroup$
In a microprocessor your program runs in "user mode", the operating systems runs in "system mode." If a user mode program executed a halt instruction, for example, the machine would not halt. The halt would be trapped and the operating system invoked. Regarding RAM, the OS would set up an environment for the user mode program so that, via memory management hardware, what the user program sees as RAM address X would not really be RAM address X.
$endgroup$
– George White
1 hour ago





$begingroup$
In a microprocessor your program runs in "user mode", the operating systems runs in "system mode." If a user mode program executed a halt instruction, for example, the machine would not halt. The halt would be trapped and the operating system invoked. Regarding RAM, the OS would set up an environment for the user mode program so that, via memory management hardware, what the user program sees as RAM address X would not really be RAM address X.
$endgroup$
– George White
1 hour ago













$begingroup$
@cyclone125 I am not referring to any architecture/OS in particular. It's just a general question.
$endgroup$
– Flux
1 hour ago




$begingroup$
@cyclone125 I am not referring to any architecture/OS in particular. It's just a general question.
$endgroup$
– Flux
1 hour ago




1




1




$begingroup$
... Long ago I used to write in raw machine code. Yee ha !!! :-)
$endgroup$
– Russell McMahon
1 hour ago




$begingroup$
... Long ago I used to write in raw machine code. Yee ha !!! :-)
$endgroup$
– Russell McMahon
1 hour ago










2 Answers
2






active

oldest

votes


















3












$begingroup$

In the end, all programs are machine code, regardless of whether the source language was assembler or a high-level language.



The important thing is that there are hardware mechanisms that limit what a given process can do, including "messing with" registers that could affect other programs or the operating system itself.



This started with a simple distinction between "user" and "supervisor" modes of operation, and has since evolved into a security architecture with multiple "rings" of privilege.




Here's a very generic example to make it a little more concrete:



  • In "user mode", a process cannot access memory that hasn't been assigned to its process ID. Memory assigned to other processes and the operating system itself is blocked. This includes the values of registers used by those other processes. This is enforced by the MMU hardware.


  • Therefore, in "user mode", a process cannot access the MMU control registers.


  • And obviously, in "user mode", a process cannot change the mode to "supervisor mode" except through a very well-defined mechanism that involves calling an operating system function.


The operating system gets control if the process tries to break any of these rules. Once that happens, the OS can simply halt the offending process, never executing any more of its instructions.






share|improve this answer











$endgroup$












  • $begingroup$
    If I understand correctly, what you're saying is: Some processors have "user mode" and "supervisor mode". The OS runs in "supervisor mode", and puts the processor into "user mode" to run my fictional assembly program. In "user mode", there are registers and RAM addresses that the assembly program cannot access due to deliberate design of the hardware.
    $endgroup$
    – Flux
    1 hour ago











  • $begingroup$
    Basically, this answer describes modern "i386-like" architectures with MMU and Protected mode. But to be true there are many old (i8080, MOS 6502 etc.) as well as modern simpler (AVR, ARM Cortex-M etc.) architectures that don't have these features and if some kind of OS is used (e.g. old CP/M, modern FreeRTOS, ChibiOS etc.) nothing can stop the program from what it is doing.
    $endgroup$
    – cyclone125
    1 hour ago











  • $begingroup$
    @Flux The i386 (and above) architectures provide details to learn. The x86 architecture not only has memory addresses that can be protected, but also I/O addresses, too. (There are different instructions used for memory access vs I/O access.) There are three memory addresses in the i386+. The segmented/selector-based address uses a selector register that references a table entry (GDT or LDT) to map the pair into a single 32-bit linear address. Paging tables then translate the 32-bit linear address into a 36-bit physical address (P-II.) Protection exists at both translation steps.
    $endgroup$
    – jonk
    1 hour ago










  • $begingroup$
    @flux your summary is correct. A program in a protected memory system with a suitable multitasking OS should not be able to crash the system with any stream of instructions. Even invalid ones - those end up at a special handler.
    $endgroup$
    – pjc50
    36 mins ago


















0












$begingroup$

Many multitasking operating systems use a data structure called a Process Control Block (PCB) to take care of the register overwrite problem. When you run your code, the OS creates a new process to keep track of it. The PCB contains information about your process and space allocated to hold register contents. Let's say process A is currently running on the processor and your code is in process B. What happens when you run your code goes something lke this:



  1. Process A's state data (register contents, program counter, etc.) are copied into its PCB.


  2. Process B's state data are copied from its PCB into the CPU registers


  3. Process B runs on the processor until it finishes or is preempted


  4. Process B's state data are copied back into its PCB


  5. Process A's state data are copied back into the CPU and it continues running


If the operating system is running as process A, then you can see how saving its registers before your program runs then copying them back into the CPU once your program ends prevents user programs from messing with what's going in other processes.



To avoid user processes writing over OS data in memory, most platforms use memory segmentation. Basically, using virtual memory, the address space a process sees can be mapped to any arbitrary range of physical addresses. As long as the processes' physical memory spaces don't overlap, it's impossible for one process to overwrite another's data.



Of course, different OSes do things differently, so this won't apply in every case. Also, on most platforms, OS processes run in a different mode from user processes and there are some intricacies there.






share|improve this answer










New contributor




jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






$endgroup$












    Your Answer





    StackExchange.ifUsing("editor", function ()
    return StackExchange.using("mathjaxEditing", function ()
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
    );
    );
    , "mathjax-editing");

    StackExchange.ifUsing("editor", function ()
    return StackExchange.using("schematics", function ()
    StackExchange.schematics.init();
    );
    , "cicuitlab");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "135"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f426641%2fwhat-stops-an-assembly-program-from-crashing-the-operating-system%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3












    $begingroup$

    In the end, all programs are machine code, regardless of whether the source language was assembler or a high-level language.



    The important thing is that there are hardware mechanisms that limit what a given process can do, including "messing with" registers that could affect other programs or the operating system itself.



    This started with a simple distinction between "user" and "supervisor" modes of operation, and has since evolved into a security architecture with multiple "rings" of privilege.




    Here's a very generic example to make it a little more concrete:



    • In "user mode", a process cannot access memory that hasn't been assigned to its process ID. Memory assigned to other processes and the operating system itself is blocked. This includes the values of registers used by those other processes. This is enforced by the MMU hardware.


    • Therefore, in "user mode", a process cannot access the MMU control registers.


    • And obviously, in "user mode", a process cannot change the mode to "supervisor mode" except through a very well-defined mechanism that involves calling an operating system function.


    The operating system gets control if the process tries to break any of these rules. Once that happens, the OS can simply halt the offending process, never executing any more of its instructions.






    share|improve this answer











    $endgroup$












    • $begingroup$
      If I understand correctly, what you're saying is: Some processors have "user mode" and "supervisor mode". The OS runs in "supervisor mode", and puts the processor into "user mode" to run my fictional assembly program. In "user mode", there are registers and RAM addresses that the assembly program cannot access due to deliberate design of the hardware.
      $endgroup$
      – Flux
      1 hour ago











    • $begingroup$
      Basically, this answer describes modern "i386-like" architectures with MMU and Protected mode. But to be true there are many old (i8080, MOS 6502 etc.) as well as modern simpler (AVR, ARM Cortex-M etc.) architectures that don't have these features and if some kind of OS is used (e.g. old CP/M, modern FreeRTOS, ChibiOS etc.) nothing can stop the program from what it is doing.
      $endgroup$
      – cyclone125
      1 hour ago











    • $begingroup$
      @Flux The i386 (and above) architectures provide details to learn. The x86 architecture not only has memory addresses that can be protected, but also I/O addresses, too. (There are different instructions used for memory access vs I/O access.) There are three memory addresses in the i386+. The segmented/selector-based address uses a selector register that references a table entry (GDT or LDT) to map the pair into a single 32-bit linear address. Paging tables then translate the 32-bit linear address into a 36-bit physical address (P-II.) Protection exists at both translation steps.
      $endgroup$
      – jonk
      1 hour ago










    • $begingroup$
      @flux your summary is correct. A program in a protected memory system with a suitable multitasking OS should not be able to crash the system with any stream of instructions. Even invalid ones - those end up at a special handler.
      $endgroup$
      – pjc50
      36 mins ago















    3












    $begingroup$

    In the end, all programs are machine code, regardless of whether the source language was assembler or a high-level language.



    The important thing is that there are hardware mechanisms that limit what a given process can do, including "messing with" registers that could affect other programs or the operating system itself.



    This started with a simple distinction between "user" and "supervisor" modes of operation, and has since evolved into a security architecture with multiple "rings" of privilege.




    Here's a very generic example to make it a little more concrete:



    • In "user mode", a process cannot access memory that hasn't been assigned to its process ID. Memory assigned to other processes and the operating system itself is blocked. This includes the values of registers used by those other processes. This is enforced by the MMU hardware.


    • Therefore, in "user mode", a process cannot access the MMU control registers.


    • And obviously, in "user mode", a process cannot change the mode to "supervisor mode" except through a very well-defined mechanism that involves calling an operating system function.


    The operating system gets control if the process tries to break any of these rules. Once that happens, the OS can simply halt the offending process, never executing any more of its instructions.






    share|improve this answer











    $endgroup$












    • $begingroup$
      If I understand correctly, what you're saying is: Some processors have "user mode" and "supervisor mode". The OS runs in "supervisor mode", and puts the processor into "user mode" to run my fictional assembly program. In "user mode", there are registers and RAM addresses that the assembly program cannot access due to deliberate design of the hardware.
      $endgroup$
      – Flux
      1 hour ago











    • $begingroup$
      Basically, this answer describes modern "i386-like" architectures with MMU and Protected mode. But to be true there are many old (i8080, MOS 6502 etc.) as well as modern simpler (AVR, ARM Cortex-M etc.) architectures that don't have these features and if some kind of OS is used (e.g. old CP/M, modern FreeRTOS, ChibiOS etc.) nothing can stop the program from what it is doing.
      $endgroup$
      – cyclone125
      1 hour ago











    • $begingroup$
      @Flux The i386 (and above) architectures provide details to learn. The x86 architecture not only has memory addresses that can be protected, but also I/O addresses, too. (There are different instructions used for memory access vs I/O access.) There are three memory addresses in the i386+. The segmented/selector-based address uses a selector register that references a table entry (GDT or LDT) to map the pair into a single 32-bit linear address. Paging tables then translate the 32-bit linear address into a 36-bit physical address (P-II.) Protection exists at both translation steps.
      $endgroup$
      – jonk
      1 hour ago










    • $begingroup$
      @flux your summary is correct. A program in a protected memory system with a suitable multitasking OS should not be able to crash the system with any stream of instructions. Even invalid ones - those end up at a special handler.
      $endgroup$
      – pjc50
      36 mins ago













    3












    3








    3





    $begingroup$

    In the end, all programs are machine code, regardless of whether the source language was assembler or a high-level language.



    The important thing is that there are hardware mechanisms that limit what a given process can do, including "messing with" registers that could affect other programs or the operating system itself.



    This started with a simple distinction between "user" and "supervisor" modes of operation, and has since evolved into a security architecture with multiple "rings" of privilege.




    Here's a very generic example to make it a little more concrete:



    • In "user mode", a process cannot access memory that hasn't been assigned to its process ID. Memory assigned to other processes and the operating system itself is blocked. This includes the values of registers used by those other processes. This is enforced by the MMU hardware.


    • Therefore, in "user mode", a process cannot access the MMU control registers.


    • And obviously, in "user mode", a process cannot change the mode to "supervisor mode" except through a very well-defined mechanism that involves calling an operating system function.


    The operating system gets control if the process tries to break any of these rules. Once that happens, the OS can simply halt the offending process, never executing any more of its instructions.






    share|improve this answer











    $endgroup$



    In the end, all programs are machine code, regardless of whether the source language was assembler or a high-level language.



    The important thing is that there are hardware mechanisms that limit what a given process can do, including "messing with" registers that could affect other programs or the operating system itself.



    This started with a simple distinction between "user" and "supervisor" modes of operation, and has since evolved into a security architecture with multiple "rings" of privilege.




    Here's a very generic example to make it a little more concrete:



    • In "user mode", a process cannot access memory that hasn't been assigned to its process ID. Memory assigned to other processes and the operating system itself is blocked. This includes the values of registers used by those other processes. This is enforced by the MMU hardware.


    • Therefore, in "user mode", a process cannot access the MMU control registers.


    • And obviously, in "user mode", a process cannot change the mode to "supervisor mode" except through a very well-defined mechanism that involves calling an operating system function.


    The operating system gets control if the process tries to break any of these rules. Once that happens, the OS can simply halt the offending process, never executing any more of its instructions.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 1 hour ago

























    answered 1 hour ago









    Dave TweedDave Tweed

    120k9149257




    120k9149257











    • $begingroup$
      If I understand correctly, what you're saying is: Some processors have "user mode" and "supervisor mode". The OS runs in "supervisor mode", and puts the processor into "user mode" to run my fictional assembly program. In "user mode", there are registers and RAM addresses that the assembly program cannot access due to deliberate design of the hardware.
      $endgroup$
      – Flux
      1 hour ago











    • $begingroup$
      Basically, this answer describes modern "i386-like" architectures with MMU and Protected mode. But to be true there are many old (i8080, MOS 6502 etc.) as well as modern simpler (AVR, ARM Cortex-M etc.) architectures that don't have these features and if some kind of OS is used (e.g. old CP/M, modern FreeRTOS, ChibiOS etc.) nothing can stop the program from what it is doing.
      $endgroup$
      – cyclone125
      1 hour ago











    • $begingroup$
      @Flux The i386 (and above) architectures provide details to learn. The x86 architecture not only has memory addresses that can be protected, but also I/O addresses, too. (There are different instructions used for memory access vs I/O access.) There are three memory addresses in the i386+. The segmented/selector-based address uses a selector register that references a table entry (GDT or LDT) to map the pair into a single 32-bit linear address. Paging tables then translate the 32-bit linear address into a 36-bit physical address (P-II.) Protection exists at both translation steps.
      $endgroup$
      – jonk
      1 hour ago










    • $begingroup$
      @flux your summary is correct. A program in a protected memory system with a suitable multitasking OS should not be able to crash the system with any stream of instructions. Even invalid ones - those end up at a special handler.
      $endgroup$
      – pjc50
      36 mins ago
















    • $begingroup$
      If I understand correctly, what you're saying is: Some processors have "user mode" and "supervisor mode". The OS runs in "supervisor mode", and puts the processor into "user mode" to run my fictional assembly program. In "user mode", there are registers and RAM addresses that the assembly program cannot access due to deliberate design of the hardware.
      $endgroup$
      – Flux
      1 hour ago











    • $begingroup$
      Basically, this answer describes modern "i386-like" architectures with MMU and Protected mode. But to be true there are many old (i8080, MOS 6502 etc.) as well as modern simpler (AVR, ARM Cortex-M etc.) architectures that don't have these features and if some kind of OS is used (e.g. old CP/M, modern FreeRTOS, ChibiOS etc.) nothing can stop the program from what it is doing.
      $endgroup$
      – cyclone125
      1 hour ago











    • $begingroup$
      @Flux The i386 (and above) architectures provide details to learn. The x86 architecture not only has memory addresses that can be protected, but also I/O addresses, too. (There are different instructions used for memory access vs I/O access.) There are three memory addresses in the i386+. The segmented/selector-based address uses a selector register that references a table entry (GDT or LDT) to map the pair into a single 32-bit linear address. Paging tables then translate the 32-bit linear address into a 36-bit physical address (P-II.) Protection exists at both translation steps.
      $endgroup$
      – jonk
      1 hour ago










    • $begingroup$
      @flux your summary is correct. A program in a protected memory system with a suitable multitasking OS should not be able to crash the system with any stream of instructions. Even invalid ones - those end up at a special handler.
      $endgroup$
      – pjc50
      36 mins ago















    $begingroup$
    If I understand correctly, what you're saying is: Some processors have "user mode" and "supervisor mode". The OS runs in "supervisor mode", and puts the processor into "user mode" to run my fictional assembly program. In "user mode", there are registers and RAM addresses that the assembly program cannot access due to deliberate design of the hardware.
    $endgroup$
    – Flux
    1 hour ago





    $begingroup$
    If I understand correctly, what you're saying is: Some processors have "user mode" and "supervisor mode". The OS runs in "supervisor mode", and puts the processor into "user mode" to run my fictional assembly program. In "user mode", there are registers and RAM addresses that the assembly program cannot access due to deliberate design of the hardware.
    $endgroup$
    – Flux
    1 hour ago













    $begingroup$
    Basically, this answer describes modern "i386-like" architectures with MMU and Protected mode. But to be true there are many old (i8080, MOS 6502 etc.) as well as modern simpler (AVR, ARM Cortex-M etc.) architectures that don't have these features and if some kind of OS is used (e.g. old CP/M, modern FreeRTOS, ChibiOS etc.) nothing can stop the program from what it is doing.
    $endgroup$
    – cyclone125
    1 hour ago





    $begingroup$
    Basically, this answer describes modern "i386-like" architectures with MMU and Protected mode. But to be true there are many old (i8080, MOS 6502 etc.) as well as modern simpler (AVR, ARM Cortex-M etc.) architectures that don't have these features and if some kind of OS is used (e.g. old CP/M, modern FreeRTOS, ChibiOS etc.) nothing can stop the program from what it is doing.
    $endgroup$
    – cyclone125
    1 hour ago













    $begingroup$
    @Flux The i386 (and above) architectures provide details to learn. The x86 architecture not only has memory addresses that can be protected, but also I/O addresses, too. (There are different instructions used for memory access vs I/O access.) There are three memory addresses in the i386+. The segmented/selector-based address uses a selector register that references a table entry (GDT or LDT) to map the pair into a single 32-bit linear address. Paging tables then translate the 32-bit linear address into a 36-bit physical address (P-II.) Protection exists at both translation steps.
    $endgroup$
    – jonk
    1 hour ago




    $begingroup$
    @Flux The i386 (and above) architectures provide details to learn. The x86 architecture not only has memory addresses that can be protected, but also I/O addresses, too. (There are different instructions used for memory access vs I/O access.) There are three memory addresses in the i386+. The segmented/selector-based address uses a selector register that references a table entry (GDT or LDT) to map the pair into a single 32-bit linear address. Paging tables then translate the 32-bit linear address into a 36-bit physical address (P-II.) Protection exists at both translation steps.
    $endgroup$
    – jonk
    1 hour ago












    $begingroup$
    @flux your summary is correct. A program in a protected memory system with a suitable multitasking OS should not be able to crash the system with any stream of instructions. Even invalid ones - those end up at a special handler.
    $endgroup$
    – pjc50
    36 mins ago




    $begingroup$
    @flux your summary is correct. A program in a protected memory system with a suitable multitasking OS should not be able to crash the system with any stream of instructions. Even invalid ones - those end up at a special handler.
    $endgroup$
    – pjc50
    36 mins ago













    0












    $begingroup$

    Many multitasking operating systems use a data structure called a Process Control Block (PCB) to take care of the register overwrite problem. When you run your code, the OS creates a new process to keep track of it. The PCB contains information about your process and space allocated to hold register contents. Let's say process A is currently running on the processor and your code is in process B. What happens when you run your code goes something lke this:



    1. Process A's state data (register contents, program counter, etc.) are copied into its PCB.


    2. Process B's state data are copied from its PCB into the CPU registers


    3. Process B runs on the processor until it finishes or is preempted


    4. Process B's state data are copied back into its PCB


    5. Process A's state data are copied back into the CPU and it continues running


    If the operating system is running as process A, then you can see how saving its registers before your program runs then copying them back into the CPU once your program ends prevents user programs from messing with what's going in other processes.



    To avoid user processes writing over OS data in memory, most platforms use memory segmentation. Basically, using virtual memory, the address space a process sees can be mapped to any arbitrary range of physical addresses. As long as the processes' physical memory spaces don't overlap, it's impossible for one process to overwrite another's data.



    Of course, different OSes do things differently, so this won't apply in every case. Also, on most platforms, OS processes run in a different mode from user processes and there are some intricacies there.






    share|improve this answer










    New contributor




    jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






    $endgroup$

















      0












      $begingroup$

      Many multitasking operating systems use a data structure called a Process Control Block (PCB) to take care of the register overwrite problem. When you run your code, the OS creates a new process to keep track of it. The PCB contains information about your process and space allocated to hold register contents. Let's say process A is currently running on the processor and your code is in process B. What happens when you run your code goes something lke this:



      1. Process A's state data (register contents, program counter, etc.) are copied into its PCB.


      2. Process B's state data are copied from its PCB into the CPU registers


      3. Process B runs on the processor until it finishes or is preempted


      4. Process B's state data are copied back into its PCB


      5. Process A's state data are copied back into the CPU and it continues running


      If the operating system is running as process A, then you can see how saving its registers before your program runs then copying them back into the CPU once your program ends prevents user programs from messing with what's going in other processes.



      To avoid user processes writing over OS data in memory, most platforms use memory segmentation. Basically, using virtual memory, the address space a process sees can be mapped to any arbitrary range of physical addresses. As long as the processes' physical memory spaces don't overlap, it's impossible for one process to overwrite another's data.



      Of course, different OSes do things differently, so this won't apply in every case. Also, on most platforms, OS processes run in a different mode from user processes and there are some intricacies there.






      share|improve this answer










      New contributor




      jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      $endgroup$















        0












        0








        0





        $begingroup$

        Many multitasking operating systems use a data structure called a Process Control Block (PCB) to take care of the register overwrite problem. When you run your code, the OS creates a new process to keep track of it. The PCB contains information about your process and space allocated to hold register contents. Let's say process A is currently running on the processor and your code is in process B. What happens when you run your code goes something lke this:



        1. Process A's state data (register contents, program counter, etc.) are copied into its PCB.


        2. Process B's state data are copied from its PCB into the CPU registers


        3. Process B runs on the processor until it finishes or is preempted


        4. Process B's state data are copied back into its PCB


        5. Process A's state data are copied back into the CPU and it continues running


        If the operating system is running as process A, then you can see how saving its registers before your program runs then copying them back into the CPU once your program ends prevents user programs from messing with what's going in other processes.



        To avoid user processes writing over OS data in memory, most platforms use memory segmentation. Basically, using virtual memory, the address space a process sees can be mapped to any arbitrary range of physical addresses. As long as the processes' physical memory spaces don't overlap, it's impossible for one process to overwrite another's data.



        Of course, different OSes do things differently, so this won't apply in every case. Also, on most platforms, OS processes run in a different mode from user processes and there are some intricacies there.






        share|improve this answer










        New contributor




        jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        $endgroup$



        Many multitasking operating systems use a data structure called a Process Control Block (PCB) to take care of the register overwrite problem. When you run your code, the OS creates a new process to keep track of it. The PCB contains information about your process and space allocated to hold register contents. Let's say process A is currently running on the processor and your code is in process B. What happens when you run your code goes something lke this:



        1. Process A's state data (register contents, program counter, etc.) are copied into its PCB.


        2. Process B's state data are copied from its PCB into the CPU registers


        3. Process B runs on the processor until it finishes or is preempted


        4. Process B's state data are copied back into its PCB


        5. Process A's state data are copied back into the CPU and it continues running


        If the operating system is running as process A, then you can see how saving its registers before your program runs then copying them back into the CPU once your program ends prevents user programs from messing with what's going in other processes.



        To avoid user processes writing over OS data in memory, most platforms use memory segmentation. Basically, using virtual memory, the address space a process sees can be mapped to any arbitrary range of physical addresses. As long as the processes' physical memory spaces don't overlap, it's impossible for one process to overwrite another's data.



        Of course, different OSes do things differently, so this won't apply in every case. Also, on most platforms, OS processes run in a different mode from user processes and there are some intricacies there.







        share|improve this answer










        New contributor




        jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        share|improve this answer



        share|improve this answer








        edited 52 mins ago





















        New contributor




        jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        answered 1 hour ago









        jtstjtst

        114




        114




        New contributor




        jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





        New contributor





        jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        jtst is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Electrical Engineering Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f426641%2fwhat-stops-an-assembly-program-from-crashing-the-operating-system%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Möglingen Índice Localización Historia Demografía Referencias Enlaces externos Menú de navegación48°53′18″N 9°07′45″E / 48.888333333333, 9.129166666666748°53′18″N 9°07′45″E / 48.888333333333, 9.1291666666667Sitio web oficial Mapa de Möglingen«Gemeinden in Deutschland nach Fläche, Bevölkerung und Postleitzahl am 30.09.2016»Möglingen

            Virtualbox - Configuration error: Querying “UUID” failed (VERR_CFGM_VALUE_NOT_FOUND)“VERR_SUPLIB_WORLD_WRITABLE” error when trying to installing OS in virtualboxVirtual Box Kernel errorFailed to open a seesion for the virtual machineFailed to open a session for the virtual machineUbuntu 14.04 LTS Virtualbox errorcan't use VM VirtualBoxusing virtualboxI can't run Linux-64 Bit on VirtualBoxUnable to insert the virtual optical disk (VBoxguestaddition) in virtual machine for ubuntu server in win 10VirtuaBox in Ubuntu 18.04 Issues with Win10.ISO Installation

            Torre de la Isleta Índice Véase también Referencias Bibliografía Enlaces externos Menú de navegación38°25′58″N 0°23′02″O / 38.43277778, -0.3838888938°25′58″N 0°23′02″O / 38.43277778, -0.38388889Torre de la Illeta de l’Horta o Torre Saleta. Base de datos de bienes inmuebles. Patrimonio Cultural. Secretaría de Estado de CulturaFicha BIC Torre de la Illeta de l’Horta. Dirección General de Patrimonio Cultural. Generalitat ValencianaLugares de interés. Ayuntamiento del CampelloTorre de la Isleta en CastillosNet.org