1

I know what is real and protected mode of cpu execution. But how CPU implements protected mode ? AFAIK cpu does everything what the program says it to do. Where is the protected mode behaviour implemented ? Does OS plays any role in this ?

  • 1
    I'm not sure if you understand what protected mode really is. From reading your question it looks for me like you think that protected mode is executing a particular instruction by the OS kernel while real mode is not - but this is wrong. I recommend to read about protected mode at Wikipedia first. – Steffen Ullrich Aug 21 '18 at 19:02
  • I have changed the language of question, I have got my understanding of both cpu modes from flint.cs.yale.edu/feng/cos/resources/BIOS/procModes.htm and manybutfinite.com/post/cpu-rings-privilege-and-protection – humble_wolf Aug 21 '18 at 19:28
  • In my view real and protected are 2 modes of cpu execution, Real mode is from ancient systems. In protected mode previlages has been distributed, Am i right ? – humble_wolf Aug 21 '18 at 19:31
  • @humble_wolf: I think the second link explains everything fairly well (look for example for the phrase "...let's see exactly how the CPU keeps track of the current privilege level...") and once you've understood the article you should be able to answer your question yourself. Maybe read it again and if still unclear ask a particular detail from this article which you did not understand. – Steffen Ullrich Aug 21 '18 at 19:41
  • 1
    I'm not sure how this is relevant to information security. This is a hardware question. – forest Sep 5 '18 at 2:58
4

There's a bit in a register that indicates whether the CPU is currently in kernel mode or user mode. Program code cannot modify this bit directly: it has to use special instructions that do more than just change this bit. Certain instructions can only be used in kernel mode; attempting to use them in user mode instead triggers a trap.

While the processor is running in kernel mode, it can switch to user mode at any time. But while the processor is running in user mode, there are only a few ways to switch to kernel mode: with the system call instruction, because of an interrupt, or through a trap. In all cases, the processor doesn't just switch to kernel mode, it also jumps to an address in memory which can only be configured by kernel code. This ensures that user mode code cannot execute whatever it wants in kernel mode. User mode can only call a few specific entry points in the kernel code, and the kernel code at these entry points can set up its processing environment carefully and validate its inputs.

All of this would be useless if user code could modify the content of memory that contains kernel code or data. It cannot due to the memory management unit (MMU). One of the functions of the MMU is to limit what memory is accessible at a given time. Memory can be marked as accessible to the kernel only, and switching between kernel mode and user mode may change the access permission table. The MMU configuration can only be modified while running in kernel mode. This way the kernel can configure the memory so that it can access its own code and data, but user code cannot.

The kernel actually maintains one MMU configuration per user process. Before switching to user mode, the kernel modifies the MMU configuration to correspond to the one for the process that will be executing after switching to user mode.

Pretty much any sufficiently advanced processor follows this basic model: not only any PC manufactured in the past 30 years, but also any smartphone and even many embedded devices.

I've simplified a lot of things. In the real world, there can be more than two privilege levels, more processor modes, more aspects of MMU configuration, etc. You have the gist of how it works. If you want to understand kernel code or write your own, you'll need to read about a specific processor architecture in more detail.

“Real mode” is a historic aspect of x86 processors. It hasn't been relevant in the real world for the past couple of decades except in some rare embedded x86 systems and to some people writing bootloaders or running some really old legacy software.

  • Is user mode and protected mode the same thing, one more thing In real mode does the program has access to all of the memory or it just emulates the 1 mb environment of 20 address pin cpu's (where it got orignated afaik) ? – humble_wolf Sep 5 '18 at 2:39
  • @humble_wolf Forget about real mode vs protected mode. Real mode is a backward compatibility thing on 32-bit x86 processors that's only used very briefly at boot time (and never used on modern PCs with a 64-bit processor and a UEFI bootloader). Only protected mode is relevant to the real world in the 21st century. User mode vs kernel mode is an unrelated concept which exists (with some variations) on most CPUs today. The kernel code runs in kernel mode and program code runs in user mode. – Gilles 'SO- stop being evil' Sep 6 '18 at 22:04
  • okay, on more thing, just because os runs first on a cpu it is able to enforce protected mode , am I right? – humble_wolf Sep 7 '18 at 3:15
  • 1
    @humble_wolf The OS (more precisely, the kernel) starts in kernel mode. It sets things up (interrupt vectors, MMU, …) so that only kernel code can run in kernel mode. The first piece of code that runs on the CPU is called a bootloader, and it too runs in kernel mode and loads the kernel (or the next bootloader stage). Indeed in terms of security whoever runs first gets to decide what happens on the system, and is responsible for configuring the system so that only trusted code runs in privileged mode. – Gilles 'SO- stop being evil' Sep 7 '18 at 6:56
  • So bootloaders can be an achilles heel wrt. security in a computer ? It can be infected to do any damage to a computer ? – humble_wolf Sep 7 '18 at 9:12
2

Protected mode and real mode are two submodes of the Legacy Mode of the x86-64 architecture. One of the differences between them is in how physical addresses are calculated. Another important difference is that protected mode introduces the concept of privilege levels and read/write/execute protection attributes to isolate and protect different programs from each other. The CPU uses the value of CR0[PE] (CR0 is just a register) on each memory access (memory data reads, memory data writes, and code fetches) to determine whether it is in real or protected mode. If CR0[PE] is 0, the CPU is in real mode. Otherwise, if CR0[PE] is 1, the CPU is in protected mode. The OS can change the mode using the MOV CRO instruction. All instructions that follow MOV CRO will be executed in the new mode. For more information, you can refer to the Intel SDM Volume 3.

  • 1
    I think "One of the differences between them is in how physical addresses are calculated." doesn't adequately describe what the difference is wrt to security. I've no doubt that your answer is technically correct, but this is security.SE :) Then again, it is a pretty broad question. – Maarten Bodewes Aug 22 '18 at 22:09
  • 1
    @MaartenBodewes Agreed. I added a bit more details. – Hadi Brais Aug 22 '18 at 22:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.