kernel - Interrupt Descriptor Table and System Call Table?

06
2014-04
  • user61954

    Anyone please help me find out the relation between these two. Read somewhere that

    "The IDT is initialized one first time by the BIOS routine but Linux does it one more time when it take control."

    So for interrupt hooking attacker have to change the contents again?

    Whether the control is moved from IDT to System Call Table in a general sense, when a system call occurs?

    • Answers
  • harrymc

    The Interrupt Descriptor Table contains addresses of routines that are called by the hardware when an interrupt is raised in the computer.

    The System Call Table is just a list of all the system calls for the operating system. This means the API. It normally has no physical existence, as it is just part of the documentation.


    • Related Question

    windows xp - Guidelines for troubleshooting high interrupt rate
  • Aaron

    Sample readings:

    • high or above normal interrupt rate (at idle), at approximately 1505/sec
    • Information obtained from Process Explorer and Kernrate
    • System calls approximately 6132/sec
    • Context switches approximately 1584/sec

    Possible faulty hardware or faulty device driver?

    Version: Windows XP 5.1.2600

    Update:

    • Possibly, investigate which user-land processes (or threads) are responsible for certain system calls and why

    • Related Answers
  • Peter Mortensen

    Do you have a USB device connected (besides the keyboard/mouse)?

    I experienced a similar problem to yours, but only if I connected a USB hard drive. The system would then go into a state that required a restart to get it out of. Even if the USB drive was unmounted the interrupt rate would still be high and the system was slow and not very responsive.

    I tried all sorts of things, including removing the USB devices in the Device Manager and updating to the latest drivers. But nothing helped. In the end I bought a new computer as it was time to get a new one anyway. The USB drive was working perfectly on the new system so it was not the source of the problem.

    I suspect it was either faulty hardware or a corrupted Windows installation.

    In general I don't like to propose unspecific measures, but:

    perhaps a first step could be to install Windows XP on a second empty hard disk and see if the problem goes away. If it does not then you can rule out a corrupted Windows installation or a corrupted file system (as it was installed on an empty harddisk).

    Using this method you can return to your old Windows installation without the need to reinstall applications, etc. The second Windows installation can also be used as a backup installation if the first one fails - this can be very handy if you don't have time to fix the problem, but just want keep on working. (I also use it to switch back and forth between a 32 bit version and a 64 bit version of Windows - although a virtual machine would probably be more handy).

  • hanleyp

    Check your drives/IDE channels in Device Manager Properties and verify that they aren't running in PIO mode. I've seen an issue like this before with a hard drive causing the system to have very slow performance. Windows XP (and higher) automatically "downshift" from DMA, or Direct Memory Access, to PIO, Programmed Input/Output, modes if problems are encountered with the data from the drive.

    If this is the problem, could change the Advanced properties to use DMA mode if available or just delete the device and let Windows reinstall the driver.