cool .... you read the article in detail .... I am glad to know that, but its really hard to figure out your own mistakes. I never read my article again before posting. Well I will take care of these suggestiong and hope to correct them by this weekend, it will take some time to fix so many typing mistakes. I appreciate your effort in find these errors .... Please have a look below for the inline answers to your questions. Putting this mail on kernelnewbies, so that other people can also put their share if they want. On 1/24/06, mohanlal jangir <mohanlaljangir@xxxxxxxxxxx> wrote: > Hi Gaurav, > I read your article titled "Interrupt Handling Internals in Linux Kernel" > and found it very useful. Your endeavors towards this are worth commending. > Although I am only halfway through your article (about to start section > "Kernel Support for Handling Interrupts"), I though to write this email with > some queries before I go into source code section. > First I list some suggestions. Most of them are related to grammatical > mistakes (which a good article should not have) > 1. At many places white space between two words is eliminated. I am > enlisting those words here (You can simply search for them). They are as > follows: > insturctionduring, Beforeexplaining, anddo, toCPU, bitis, whoseaddress, > withthe, performedfor, byassembly, oncewe etc (These are till section > "Kernel Support ..."). > > 2. There are some typos. I list the statement with correction > > each line connected to different divice contollers in system > divice !! contollers should be controllers. > Here are the answers .... > Ah.. lot of suggestions... now questions start > 1. "The only difference between trap gates and interrupt gates is that, > whenever an interrupt gate is hit, CPU automatically disables the interrupts > by clearing the IF flag in CPU's EFLAG register, whereas in case of trap > gate this is not done and interrupts remain enabled" > Does it mean during interrupt gate hit and its servicing, further interrupts > will lost (until IF bit is set again)? No, I thnk interrupts are not lost, they are remembered by PIC till the time CPU does not acknowledge them. So when IF flag will be cleared, interrupts are sent to CPU by PIC but are ignored by CPU and CPU does not acknowledge them, so PIC remembers them. Once the interrupts are enabled again, PIC send the pending interrupts. > > 2. Is DPL value stored both in GDT and IDT? If yes, what is significance of > each? > Yes DPL is a field in both GDT and IDT entries, but both may have different value and definitely have a different significance. Explained their significance below. > 3. "This is the reason that in Linux, DPL fields of all the IDT enteries > (except 128th entry used for system call) are initialized with value '0', > this makes sure only kernel code can access these gates not application > code" > Since Linux uses two privilege levels only (0 and 3), therefore condition > DPL (of GDT entry) <= CPL is always true (condition 4a in section "Hardware > Checks for Interrupts and Exceptions") First lets understand whats the use of DPL of GDT entry. It is actually used to check, if we are entering a segment with high priveliege (low DPL value than the CPL, or in other way DPL < CPL). If this is the case, CPU performs the stack switch as explained in article. The case for this will be when we are in user space (CPL = 3) and an interrupt occurs for which the DPL of GDT entry is 0. If DPL is equal to CPL (DPL = CPL), CPU dont do stack switching, because we are entering the segment with same level. The case where DPL = CPL is when we are already in kernel mode (CPL = 0) and an interrupt occurs (DPL for the corresponding GDT entry will be 0) So the use of DPL field of GDT is for CPU to decide, if to switch the stack automatically or not. Kernel initilizes the DPL field of GDT entries (which are pointed by IDT) to value 0, which always satisfies the condition DPL<= CPL, this is reason that no general protection exception occurs. If you change these DPL values in GDT to 3 and boot your machine with recomplie kernel, you find alot of genral protection exception occuring (make your system fail totally) when you are in kernel mode and interrupts are occuring. > as well as > DPL (of IDT entry) >= CPL is also always true (condition 5a in same section) > Similarly conditions 4b and 5b are always false. > I am wondering in what case general protection exception will be triggered. > And how application code is prevented by accessing IDT entries (except 128)? > DPL of IDT entry have different significance from DPL of GDT entry. DPL of IDT entry is used to make sure that who all can access or get an entry through this IDT gate. Only those flow of execution are allowed to pass these gates for which CPL <= DPL of IDT entry, else and genral protection exception will occur. This means if we set the DPL of an IDT entry to 3, that can be accessed by both user code (use space, CPL = 3) and kernel code (kernel space, CPL = 0), but on other hand if we set the DPL ifan IDT entry to be 0, that entry can not be accessed from user space (CPL = 3), because here CPL > DPL and fails the required condition, in this case CPU will generate the general protection exception. To try this general protection exception, write simple C programme which tries to do "int 0x40". When this instruction will be executed, CPU will generate the genral protection exception and the handle of genral protection exception will send SIGSEGV signal to your programme and your programme will segment fault. This is the reason that for DPL field of all the entries except entry 128th of IDT (used for system call entry, need to be invoked by user space) are set to 0, this setting makes sure that user space execution flow does not enter to kernel spce through these gates, only one gate is made open for that and that is entry 128th of IDT through with user spcae execution flow can enter the kernel space (for this 128th entry, DPL value is 3). > 4. Which memory IDT and GDT stored? Is it L2 cache? I think this is in simple RAM, not sure about it. Hope these answers clears your doubt. Thanks once again for going through the article and pointing out some good suggestions. regards, -Gaurav > > Thanks and regards, > Mohanlal > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
