Note that we did not fault on the user's code. If there wasn't the
lock-prefix, the user's code would have caused an illegal instruction
trap. All we did, so far, is arrange a way of getting the CPU to
ignore the lock-prefix.
Control will return to the instruction that caused the page-fault which
is not the lock-prefix.
You can easily check this on the present kernel by modifying the
F00F trap to just load the good IDT and then goto the "out:" label
in fault.c. The first occurance of the F00F instruction properly
causes a user-mode illegal instruction trap. The problem is that
a "good" IDT is now present <forever> and the second time you
try to crash the system, you will. So the idea is to have the
kernel get control to restore the "bad" IDT.
Now, after considerable thought, and the reason why I am c.c.ing this
to linux-kernel, the IDT really doesn't have to be reloaded either. The
bottom part can really exist in memory, but its page can be marked as "not
present". There is a bit for this in the page-table. It is possible to
perform the same function without reloading anything. I think that the
handlers for the first 6 traps can mark the page as not present after
they execute and the kernel starts with that page marked not present.
Then the code-flow is:
(1) User executes bad instruction
(2) CPU page-faults because IDT lower page is not present.
(3) Kernel PF routine marks lower IDT page present.
(4) Control returns to user (it's restartable).
(5) User code traps to proper kernel handler.
(6) Kernel handler marks IDT lower page not present.
Everybody lives happily thereafter.
Even CPUs that are not faulty could do this. Marking a page
present or not present does not use many CPU cycles. It's
a normal virtual memory thing.
Cheers,
Dick Johnson
Richard B. Johnson
Project Engineer
Analogic Corporation
Penguin : Linux version 2.1.63 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.