flat assembler
Message board for the users of flat assembler.

Index > Windows > HARDWARE MASTER DRIVER

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Pirata Derek



Joined: 31 Oct 2008
Posts: 259
Location: Italy
Pirata Derek
No, my drivers store all the original gates into a buffer before making the hook. (Also it stores the IDTR)

It has only to check if the original gate is the same as the hooked gate.
If is the same then skip the hooking, else then continue hooking.

For a fast check it will compare only the IDTRs.
(it doesn't care the others registers like GDT, because the driver automatically saves the correspondings selectors for each interrupt vector)

(i'll make these modifications soon)
Post 12 Jan 2010, 15:48
View user's profile Send private message Send e-mail Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
QEMU does full hardware support, so it can simulate multi-core systems even on a single-core host machine; this at least allows for basic testing. A good deal slower than the real thing, yes, but there's also some support for the same tricks vmware and others do: trying to run code natively, when it can be done safely. Haven't tested this myself, last time I needed QEMU that native-execution driver was linux-only.

Oh, and it is full machine state emulation... but of course you won't really run the the emulated cores in parallel, which means some possible multicore bugs (especially those involving (non)atomic memory operations) won't be detected... I don't know if the cores are run round-robin per emualtion cycle, or if they're run in random order per cycle - sequential order reduces the risk of race conditions firing off. Life's a bitch Smile

Btw, does windows really set up a GDT and IDT for each core? Obviously each core has it's own GDT and IDT pointers, but couldn't the structures be shared? Am I missing some obvious reason for separate tables? Smile (avoiding having to do mutual exclusion could've been a reason, but will Windows modify GDT/IDT after kernel bootstrapping phase?)
Post 12 Jan 2010, 16:12
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
ouadji, Zw* functions from NTDLL.DLL are for ring 0 use. For instance ZwCreateFile is for kernel-mode and NtCreateFile for user-mode.
Post 12 Jan 2010, 16:14
View user's profile Send private message Reply with quote
Pirata Derek



Joined: 31 Oct 2008
Posts: 259
Location: Italy
Pirata Derek
For me is more convenient that all the cores have the same IDT because any different IDT requires more memory space in RAM.

If not, the system must work more for many reasons.
ONE EXAMPLE (differents IDT) that have 2 cases:

1) The system should share (reply) all the ISRs gates, between the cores IDTs, when a driver creates and connect its service routine (eg. network Miniport) so that driver code can be executed by all cores.

2) When a driver (eg. network miniport) create and connect its ISR, the system registrates that vector only in one IDT core, but this ISR is only executable by that core.

In both cases there is a little disadvantage!
Post 12 Jan 2010, 16:35
View user's profile Send private message Send e-mail Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji
Quote:

f0dder :
does windows really set up a GDT and IDT for each core ?


Yes, of course! With Windows XP Pro
there is a table IDT and GDT separate in memory for each processor
and, of course, a different value for each IDTR/GDTR.

screenshot from Syser
Image
Quote:
LocoDelAssembly :
For instance ZwCreateFile is for kernel-mode and NtCreateFile for user-mode.

yes, you're right LocoDelAssembly ! sorry for the mistake.

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 12 Jan 2010, 17:03
View user's profile Send private message Send e-mail Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
ouadji wrote:
Yes, of course!
Why "of course"? I'm interested in why it does it, not just that it does it Smile

Is it a requirement for each core to have it's own separate table, or is there another good reason? I can't see why multiple GDTs make sense in a flat memory model, since you only need a few of them...

I guess separate IDTs have uses, like dedicating processing of device IRQs to a single core, but... *shrug*. Can anybody shed some light on why it's being done? Smile
Post 12 Jan 2010, 18:02
View user's profile Send private message Visit poster's website Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji

Sorry for my english, i do my best.
This allows to assign a different interrupt vector for each processor and for the same interrupt.
Different code for each processor, but for the same "INT".
This has nothing to do with the flat model or not !
This allows you to connect a processor on a code_dispatcher, and not others.
With a hook ... but also with "IoConnectInterrupt", you can do that.

Code:
IoConnectInterrupt
OUT PKINTERRUPT  *InterruptObject,
IN PKSERVICE_ROUTINE  ServiceRoutine, <--- this "ServiceRoutine"
IN PVOID  ServiceContext,                  for 1 µP (or 2 ...) and not the others.
IN PKSPIN_LOCK  SpinLock  OPTIONAL,
IN ULONG  Vector,
IN KIRQL  Irql,
IN KIRQL  SynchronizeIrql,
IN KINTERRUPT_MODE    InterruptMode,
IN BOOLEAN  ShareVector,
IN KAFFINITY  ProcessorEnableMask, <<------------- ! Affinity Mask
IN BOOLEAN  FloatingSave 
    

To allow this, different "IDTs" are essential
Quote:
but will Windows modify GDT/IDT after kernel bootstrapping phase?
Windows, maybe not (but also ... why not) , but the user can do that.

_________________
I am not young enough to know everything (Oscar Wilde)- Image


Last edited by ouadji on 12 Jan 2010, 18:53; edited 5 times in total
Post 12 Jan 2010, 18:15
View user's profile Send private message Send e-mail Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3055
Location: vpcmipstrm
bitRAKE
/me wonders if multiple GDTs used for NUMA?
Post 12 Jan 2010, 18:47
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
ouadji: I'm aware that multiple IDT tables are necessary to have the same interrupt perform different actions on different CPUs - that's pretty much self explanatory Smile - I'm wondering why you'd want to do that.

My comment about GDT was separate from the IDT comment. Since Windows uses a non-segmented/flat address space, it only needs a very limited amount of descriptors, and as far as I can tell there shouldn't be a problem using the exact same descriptors across multiple cores?

bitRAKE: hm, dunno - what's your thoughts on this? Can't think of a reason why it'd be useful off top of my head... isn't the memory still addressed the regular way (linear->(paging)->physical and all) but "just" have some added mapping tables that give topology information?
Post 12 Jan 2010, 19:56
View user's profile Send private message Visit poster's website Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji

Quote:
I'm wondering why you'd want to do that

Not me, I'm not smart enough to use it. Very Happy

But I think this option is used by some complex programs ...
virtual machine, debugger, Blue Pill perhaps Wink ...
Having said that, even to develop things much simpler,
I have no choice, i have to manage these multiple IDTs.

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 12 Jan 2010, 20:56
View user's profile Send private message Send e-mail Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3055
Location: vpcmipstrm
bitRAKE
f0dder wrote:
bitRAKE: hm, dunno - what's your thoughts on this?
I cannot imagine anything that would be gained by using GDTs for NUMA besides an added layer of protection from page table / mapping errors.

_________________
¯\(°_o)/¯ unlicense.org
Post 13 Jan 2010, 00:56
View user's profile Send private message Visit poster's website Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji

you talk about NUMA, what is NUMA ?
Thank you.

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 13 Jan 2010, 09:27
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17715
Location: In your JS exploiting you and your system
revolution
ouadji wrote:

you talk about NUMA, what is NUMA ?
Thank you.
See my website for the answer. Twisted Evil

Sorry, I couldn't resist. Wink
Post 13 Jan 2010, 09:38
View user's profile Send private message Visit poster's website Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji

your webside ... ok !
Members List / revolution / webside = http://justfuckinggoogleit.com/
sorry, but I do not see anything about "NUMA Razz Razz
That said, a little explanation would have been nice.

About multiple IDTs, there is also your Webside, no ?
and if we delete the forum ?
After all, all answers can be found on Google ! Wink

Thank you a lot f0dder. (below)

_________________
I am not young enough to know everything (Oscar Wilde)- Image


Last edited by ouadji on 13 Jan 2010, 10:18; edited 5 times in total
Post 13 Jan 2010, 09:52
View user's profile Send private message Send e-mail Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Well, assuming you have a use for separate IDT per core, I guess it could be implemented in two ways... either by having per-core IDT with different entries - or having a single IDT, but separate GDTs with IDT-related descriptors having per-core base addresses. This would be kinda messy though. I still don't see a reason for per-core tables, though, in the context of a normal operating system (doesn't mean you don't have to support it when writing driver code, though Smile).

ouadji: basically it's a way to say that "all memory is not equal" - for each core you can have "near" and "far" memory, with "far" memory being accessible but slower. Think really huge multi-core systems with multiple memory buses or something... and revolution's link will offer you a much better description Wink - or just the wikipedia entry.
Post 13 Jan 2010, 09:55
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3055
Location: vpcmipstrm
bitRAKE
Very Happy I have 8 cores like this:
Code:
uP uP  uP uP     uP uP  uP uP
 |  |   |  |      |  |   |  |
  L2     L2        L2     L2   (6MB each)
   |      |         |      |
   --------         --------   (L5410)
       |               |
       ---- 5100 MCH ---
              |  |
             Memory            (12GB)    
...definitely not equal.


Last edited by bitRAKE on 13 Jan 2010, 10:58; edited 1 time in total
Post 13 Jan 2010, 10:54
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Well, they have pretty much equal access to the RAM, don't they? Afaik NUMA doesn't cover caches?
Post 13 Jan 2010, 10:56
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17715
Location: In your JS exploiting you and your system
revolution
Definitely IS equal. All uP's have the same distance to traverse to get data from memory.
Post 13 Jan 2010, 10:57
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3055
Location: vpcmipstrm
bitRAKE
So, nothing is gained from executing code on two cores sharing L2 cache?
Post 13 Jan 2010, 11:00
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17715
Location: In your JS exploiting you and your system
revolution
bitRAKE wrote:
So, nothing is gained from executing code on two cores sharing L2 cache?
It might even hurt. If the two tasks use different data sets then they may fight for use of the cache. But this is a problem to be solved at both the OS and APP levels simultaneously.

Since you have one partition of 12GB memory then it is SMP. If you had 2 partitions of 6GB memory with some cross connect to (like QPI or hyper-transport) to deliver data amongst CPUs then it is NUMA.
Post 13 Jan 2010, 11:05
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.