[Victor43]

Hello everyone. Thanks for taking the time to review this post. Can any of you tell me how can I write code which by passes any Windows API on how to power on and making active a secondary CPU core ? The key note here is by passing the use of any Windows API. I need to write code that communicates directly with the main or primary core via Assembly or C. I am aware of the requirement of reviewing the respective datasheet but would anyone have any code samples for either architecture which I could use a basis of understanding the overall process. Please feel free to ask any questions or make any comments or recommendations. I'm not certain that this can be done by way of a user mode application but perhaps someone can provide details on how to do this either by way of kernel mode or user mode.

[Vrtule]

Hello,

the communication can be made through a block of memory guarded by a lock. You can implement your own locks by using intristics like InterlockedExchange or InterlckedCompareExchange (or take a look at cmpxchg, cmpxchg8b and similar instructions, including the lock prefix).

[feryno]

All CPUs/cores are already initialized and running, it is a task of kernel. When you boot via /onecpu switch, then OS lets application CPUs inactivated and runs only at bootstrap CPU. OS activates application CPUs by sending INIT-SIPI sequence (interprocessor interrupts). In APIC mode it is done via writing into APIC memory page and in x2APIC mode it is done via wrmsr into APIC MSRs. This cannot be done from usermode, you need kernelmode driver. The best is to let it to OS. When you boot via /onecpu and activate application CPUs later by your own driver, OS won't use them and also remember every activated CPU starts in real mode.

the steps would be:
boot with /onecpu switch
read MSR_IA32_APIC and determine whether APIC or x2APIC
for x2APIC every IPI (interprocessor interrupt) will be written via MSR (read CPU manuals)
for APIC mode you need to map APIC base (physical memory usually 0xFEE00000 obtained via the above rdmsr) via MmMapIoSpace with MmNonCached memory type and then perform writes into this page (to the offset of ICR2 and ICR), you can do it by one CPU after one (as ms win OS) or by broadcasting IPI to all_but_me at once using one command (writing shortcut into ICR).

And my suggestion is not to do that from running ms win OS, but use some emulators like BOCHS, SimNow 4.6.2 public etc.
Such code to play with activating AP CPUs fits into small bootsector which you can load safely into emulator.
http://forum.osdev.org/viewtopic.php?f=1&t=28737
http://forum.osdev.org/viewtopic.php?f=1&t=28674
http://forum.osdev.org/viewtopic.php?f=1&t=25911
http://forum.osdev.org/viewtopic.php?f=1&t=24973

[Victor43]

Hello feryno and Vrtul. Thank you both for the responses.

Two questions when a PC system is powered on:

1. On system boot up does Windows execute code which powers on secondary cores ?

2. If the answer to 1. is yes then can Windows power on and make active a secondary core on demand once the system has completed the entire boot process ? So in other words can the primary core core0 be programmed using Boolean logic gates to power on a secondary core core1 on demand by either Windows or some user mode level code ?

Thank you

[Vrtule]

Ad 2)
Windows supports processor hotplug – you can add a processor to a running system and the system is able to cope with it. Drivers can register a callback function that is invoked when a new processor is being added. It is aslo possible to block the operation.

However, I am not sure whether it is possible to simulate processor hotplug by starting the system with the /onecpu switch and then informing it somewhat that a new processor was just plugged in. I doubt so.

[Victor43]

Thanks everyone for the helpful responses. I have another question regarding making an undocumented core active. I'm associated with a company who has been investigating RF based backdoors in the Intel AMD CPU line of products. There is a possibility that the backdoor core (CPU) is already powered and executing the backdoor embedded OS. However if this is not the case then I would like to learn whether there is a possibility of constructed some user or kernel mode application which could initiate the sequence opcodes and or specially crafted code of making this undocumented core active (by way of the primary or main core) and to manipulate this core to begin RF transmissions. Can anyone share their knowledge of whether special and undocumented opcodes could be embedded within the backdoor core which we could somehow execute and attempt to manipulate the core to commence some sort of RF transmission ? We do know that the backdoors have a special routine which would transmit the video data of the users screen once the backdoor is activated.

One other note we have reason to believe that the backdoor system is loaded and executing even before the BIOS and native OS has an opportunity to load and be executed.
Please try to work with me and questions about how and why we believe the backdoor system exist should be excused. The company I am associate with has been investigating for over 1.5 years and has documented quite a large amount of details and information.

Comments would be greatly appreciated.