Overall, you are violating so many assumptions that it is amazing that
anything at all works.
Hooking IDT code is not only dangerous, but as soon as you start playing
with weird ideas like sending EOIs, only works on x86 machines with certain
motherboards and chipsets, is likely to trigger certain anti-rootkit
detectors, and involves manipulating hardware you are not supposed to have
access to.
I see a lot of this sort of thing: “I want to write code in Windows that
looks just like what I would write on a bare x86 machine” and this is not a
viable approach. There is no reason to be hooking the IDT because you
really have no idea what values are being set up by the PCI BIOS. This
looks like the “don’t tell me about the way drivers are written, I know the
bare hardware and I don’t want anything between me and it” which is not a
healthy approach. It is like the people who want to write direct to the
on-card video buffer when doing graphics (not using GDI, Direct2D or
Direct3D interfaces, because that’s for wimps who don’t understand
hardware).
You are making so many assumption here that your code could possibly be
valid that the slightest change in the behavior of the system (up to and
including hotfixes, BIOS upgrades, etc.) will (and probably should) break
it.
An operating system is a delicate ecosystem, and relies on the correct
behavior of critical pieces of the framework in which it lives. Hooking the
IDT puts you outside this framework, and leads to code that is only barely
usable on any machine other than the one it is developed on. The code is
unmaintainable, expensive to develop in the first place, and, as I pointed
out, is vulnerable to security software declaring it to be invasive (and
very rightly, defeating the attempt to do it).
Why can’t you juse do IoConnectInterrupt? Then everything works. Please
explain the rationale of why such a strange solution as the one you propose
is required.
[I’ve found in general that answering bad questions is the wrong approach;
finding out why the bad question was asked in the first place, and the
rationale behind bad choices, is far more critical…it allows directing the
OP to the correct answer, instead of a response that tells them how to make
their bad idea “work” (for suitably small values of “work”)]
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, June 03, 2010 1:16 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] EOI and Software interrupt
I’m not sure but I think that if you do that you aren’t involving the
APIC, and if you are hooking the IDT slot directly then Windows doesn’t even
get involved so you shouldn’t need to send an EOI.
I think EOI is not OS specific.
Is it a single CPU system? If not, have you hooked the IDT on all CPUs?
I have a multi-processor system (intel dual core), and I have already hooked
ISR in IDT’s of all CPU’s.
Changing my code just to make is more clear
_declspec(naked) IsrCode()
{
_asm lCounter, 0x100 //A test value
_asm iretd
}
Now at the end of driver, “net stop MyDriver”, I output “lCounter” value to
a file which 0x100 (desired value), but system starts to go bizarre after a
while. So things stop working such as switching b/w windows (user mode) from
task bar at the bottom.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.