[Sage_sage]

Imagine any user-level application can access and modify all the processor registers,
including flags. Describe the danger of this possibility. Give example of what can go
wrong. Does this approach has any positive sides?

[_eb75_]

Let's take only one and very clear example:

Any process can modify processor status register (or any equivalent register depending on the register naming and the processor in question). We have one bit telling are interrupts enabled or not. One process sets interrupts are not enabled any more. Then no interrupts will happen before next boot. The computer is frozen totally.
The operating system is helpless, because it can't recover without an interruption which could give a possibility to it to crash the oddly behaving process and fix the damage.

No benefits.

[_eb75_]

Answer may be simple and may be clear. Still it is far from complete.

Reader can get an idea that necessarily if a process clears interrupt the system hangs.

1. Show an example of a program, which clears interrupts but everything continues still correctly.
2. What about multiprocessor systems? How to hung all CPUs by using only this interrupts clearing. Any task is run only on one CPU.
3. You can answer something, but how I can verify it is correct what you say?

[_eb75_]

1. An example of the case that disabling interrupts will not cause any harm:

int i;//Linux OS
main() {
_asm_ ("cli;");//We disable interrupts (Intel/AMD).
i=i/0;// Causes the divide by zero fault, faults can't be disabled.
while(1);
}

The fault happens after some nanoseconds after disabling interrupts. Divide by zero causes fault.
OS handles the fault and crashes the current task and starts an other with interrupts enabled.
No harm done, because during some ns we have not lost anything important- hopefully.

If we comment the line i=i/0 in the above code, the processor hangs until the next boot.


2. SMP (many processors):

A "cli"-instruction most probably hangs only one processor running the "bad" task (can depend on the system and error handling of OS).

What if we run (Linux) the code:

int j;
main(){
for (j=0;j<100;j++)
if(fork())
{
 sleep(5);//We sleep 5 seconds to wait tasks are divided to run queues of procssors, otherwise first running task with cli stops our experiment.
_asm_ ("cli;");
}
}

Here we start 100 tasks. Hopefully (and probable) tasks are divided between all CPUs (for example 2- 4).
If every processor is poisoned with a "bad" task, every processor is useless.

Simulate the above case (Linux) with:

#define work_as_parlament()  while(1)
long j;
main(){
for (j=0;j<100;j++)//100 could be replaced with the number of your CPUs, but then it is pssible that
if(fork()) work_as_parlament(); //more than one of the forked tasks is scheduled to one CPU - leaving one free
}

Look at the system monitor. Is the load of all processors about at the same level (100%)?
This proves the scheduling of "bad" tasks to all CPUs.
(Monitor works still fine (Linux has the round robin multilevel queue scheduling.)

3. How, we can experiment are the answers correct.

Many ways, one example:

1. Use Linux
2. Install KML- patch// Kernel Mode Linux (for "kernel capable tasks" to some extent)
3. Compile the kernel
4. Put the experiment program to the directory /trusted
5. Compile/run the program

Still we are far from complete.

[_eb75_]

I was waiting the following question (nobody did):

Now I understand what you mean by saying "far from complete".
Your test program disabling interrupts and causing divide by zero fault would work probably exactly as you say.
It would not take the CPU away from the system.
But what about the real reason not to stop CPU?
Sad thing is that the test case you suggest do not reveal that your explanation is not correct.

What I would answer to this question:

You are right.
If we add the line i=0; in the beginning of the program then my explanation is correct (I hope).

Clearly what happens when we run the original program is:

• The program causes a page fault when starting to run, because the code is not in the RAM (demand paging, Linux).
• Then interrupts are disabled because of cli (OS can't throw the task away and CPU continues execution of instructions).
• Then (in the original code) we must access to the data memory location storing the variable i (when we start to execute i=i/0;)
• This causes a page fault.
• The page fault handler starts a disc DMA to read data page containing the variable i.
• Then comes scheduling of the next ready process to run with interrupts enabled!
• The end result is that interrupts are enabled BEFORE divide by zero fault.

If we have the line i=0 in the beginning of the code, the line i=i/0, do not cause a page fault any more and the real reason to the system to work is the divide by zero fault.

The Sage_sage's original question seems to reveal many things, a good question.

The answer is far from complete even now.
For ex. it is not explained why while(1); is necessary or is not necessary (in the case we have not divide by zero and we want to stop one CPU) and so on.................

I was using Linux as an example. Not a good thing. Would have been better to talk only at a general level. If somebody asks something difficult (about Linux) based on my example, I can't answer.
I think it is easier to write your own small kernel (what I have done) than try to follow how all things are done inside Linux kernel (4000000 code lines). Every OS can do some things at it's own way, even general principles are the same.

[_eb75_]

Far from complete answers?

Yes, what about cpu recovery from "cli".



With important real-time applications we have had for a long time a watchdog timer (HW interrupting cpu to answer somehow "I am alive"). For example we have main control computer and standby computer taking care of the system if the main computer is down.


What about Linux? What kind watchdog- have we one? We can compile the Linux kernel with or without watchdog.
What the Linux watchdog does?


On many(!) x86/x86-64 type hardware there is a feature that enables us to generate 'watchdog NMI interrupts'. It's even possible to disable the NMI watchdog in run-time by writing "0" to /proc/sys/kernel/nmi_watchdog. If any CPU in the system does not execute the period local timer interrupt for more than 5 seconds, APIC tries to fix the situation by a non-maskable interrupt (cpu executes the handler, and kills the process)! (SCC Linux is an different case as to NMI.)


My answers (in the original question) were based on the system without watchdog! It is problematic to answer at a general level and give examples based on some fixed system. The answers can be correct or depending the cpu and configuration and settings.