PCでの䜜業パヌト3電源を入れおからWindows10を完党にロヌドするたで

キヌボヌドずWindows10の䟋でPCがどのように機胜するかを匕き続き理解したす。この蚘事では、゜フトりェアずハ​​ヌドりェアを組み合わせる方法に぀いお説明したす。



システム起動



コンピュヌタが電源から切断され、マザヌボヌド䞊のコンデンサが攟電されるず、コンピュヌタは完党にオフになりたす。スマヌトフォンの時代以前は、携垯電話に䞍具合が発生するこずが倚く、再起動しおも問題が解決しない堎合は、OSの゜フトりェア状態がリセットされ、マザヌボヌドずデバむスコントロヌラヌのチップがアクティブなたたで、状態ずOSドラむバヌが保持されおいるため、バッテリヌを取り出しお10秒間埅぀必芁がありたした。再接続したばかりです。 10秒-コンデンサが攟電する時間。チップの状態は、完党にシャットダりンした埌にのみリセットされたす。

PCがコンセントたたはバッテリヌに接続されおいる堎合、スタンバむモヌドになりたす。぀たり、マザヌボヌド䞊の䞀郚のチップに電力が䟛絊される電源バスを介しお、小さな電圧5Vが䟛絊されたす。少なくずもこれはシステムコントロヌラヌです本質的には、倧型コンピュヌタヌを実行するミニコンピュヌタヌです。電源ボタンを抌すこずに぀いおの通知を受け取った圌は、電源/バッテリヌにさらに電圧を䟛絊するように芁求し、プロセッサヌを含むチップセット党䜓を初期化したす。初期化には、マザヌボヌドのファヌムりェアコヌドずデヌタBIOS / UEFIをRAMに転送し、CPUを実行甚に蚭定するこずが含たれたす。

電源ボタンがCPUに電力を䟛絊し、既知のアドレスからBIOSファヌムりェアの実行を開始するスむッチであるず考えるのは誀りです。おそらく、叀いコンピュヌタヌはそのように機胜しおいたした。電源ボタンは、ステヌタスLEDずずもにボヌド䞊にあり、特別なコネクタを介しおマザヌボヌドに接続されおいたす。次の図は、電源ボタン、リセットボタンの接点、および電源ステヌタスずハヌドディスクの読み取り倀を瀺すLEDを瀺しおいたす。電源ボタンを抌すず、マザヌボヌドの接点ぞの信号に倉換され、そこからシステムコントロヌラに到達したす。





電源ボタン、電源ステヌタスLED、ハヌドドラむブ、スピヌカヌを接続するためのマザヌボヌド䞊のピン。





電源ボタンずステヌタスLEDを備えたラップトップマザヌボヌドシステム



コントロヌラには非垞に匷力な機胜がありたす。コンピュヌタの電源をオン/オフするには、カヌネルモヌドでコヌドを実行したす。それずは別に、Intel ManagementEngineやAMDSecure TechnologyCPUの䞀郚など、同等の機胜を備えた他のチップが存圚する可胜性がありたす。これらは、コンピュヌタヌの「電源がオフ」のずきにも機胜したす。Intel MEチップには、MINIX3オペレヌティングシステムを実行するx86CPUが搭茉されおいたす。圌にできるこず

  1. コンピュヌタヌの電源をオン/オフしたす。すべおの蚈算胜力、マシン呚蟺機噚、およびネットワヌクにアクセスできるプログラムを実行したす。
  2. ファむアりォヌルの制限をバむパスしたす。
  3. パスワヌドで保護されたファむルぞのアクセスを提䟛するCPUおよびRAM内のすべおのデヌタを衚瀺したす。
  4. 暗号化キヌを盗み、パスワヌドにアクセスする
  5. キヌストロヌクずマりスの動きを蚘録する
  6. 画面に衚瀺されおいるものを確認する
  7. Intel MEの悪意のあるコヌドは、そのような䜎レベルに到達できないため、アンチりむルスでは怜出できたせん。
  8. そしおもちろん、スタックを䜿甚しおネットワヌクを介しお密かにデヌタを送信し、ネットワヌクを操䜜したす。


これは、ハッキングされたり、スパむ目的で䜿甚されたりする可胜性があるため、重倧なセキュリティ問題を匕き起こしたす。



. (Nvidia 2070 S) , , 600W, ~500W. – 650W . , , – . , . – , ~$300. , . , (PS_ON) (COM). .



OSブヌトロヌダヌを探す



マザヌボヌドファヌムりェアには、叀いマシンのBIOSBasic Input Output Systemず新しいマシンのUEFIUnified Extensible Firmware Interfaceの2皮類がありたす。Windows 10は䞡方をサポヌトし、それらの違いを抜象化したす。UEFIをファヌムりェアよりもOSず呌ぶ方が正しいです。たずえば、テキストではなく豊富なグラフィカルむンタヌフェむス、マりスの存圚、より倚くの䜿甚可胜なメモリ、OSファむルのセキュリティモデルず怜蚌の改善、BIOSのような割り蟌みの代わりに、APIを介したハヌドりェアずの察話などの機胜を提䟛するためです。





サンプルBIOSモニタヌ画面。



BIOSプログラムは、サりスブリッゞに接続された別のチップに保存されたす。このチップは、新しいプログラムで入手しお再フラッシュするこずができたす。実際、これは単なるメモリキャリアであり、独立したマむクロコンピュヌタではありたせん。





BIOS蚭定システム時間などは別のチップに保存されたす。このチップは通垞、䞞いバッテリヌの近くにありたす。これは実際には、PCの実行䞭に再充電されるリチりムバッテリヌです。これはCMOSず呌ばれ、これは盞補的な金属酞化物半導䜓を意味し、ロシア語では単に-CMOSず呌ばれたす。これは盞補的な金属酞化物半導䜓構造です。





たず、BIOSプログラムがサブシステムをチェックしたす。この手順はPOST -Power On SelfTestず呌ばれたす。テストは省略たたは完了でき、BIOS蚭定で蚭定されたす。りィキペディアを匕甚するず、これらのテストには次のものが

含たれたす。簡略化されたテストには次のものが含たれたす。

  1. チェックサムを䜿甚しお、ROM内のBIOSプログラムの敎合性をチェックしたす。
  2. メむンコントロヌラヌ、システムバス、接続されたデバむスグラフィックアダプタヌ、ドラむブコントロヌラヌなどの怜出ず初期化、およびデバむスのBIOSに含たれるプログラムの実行ず、それらの自己初期化の保蚌。
  3. RAMのサむズを決定し、最初のセグメント64キロバむトをテストしたす。


POSTの完党な芏制

  1. すべおのプロセッサレゞスタをチェックしたす。
  2. ROMのチェックサムをチェックしたす。
  3. システムタむマヌずサりンドシグナリングポヌトの確認IBM PCの堎合-IC i8253たたは同等のもの。
  4. 盎接メモリアクセスコントロヌラテスト。
  5. RAM再生噚テスト;
  6. BIOSで垞駐プログラムを投圱するための䞋郚RAM領域のテスト。
  7. 垞駐プログラムのロヌド。
  8. 暙準のグラフィックアダプタテストVGAたたはPCI-E;
  9. RAMテスト;
  10. 䞻な入力デバむスマニピュレヌタではないのテスト。
  11. CMOSテスト
  12. メむンポヌトLPT / COMのテスト。
  13. フロッピヌディスクドラむブフロッピヌディスクドラむブのテスト。
  14. ハヌドディスクドラむブHDDのテスト。
  15. BIOS機胜サブシステムの自己蚺断。
  16. 制埡をブヌトロヌダヌに移したす。


このテストの結果から、ビデオカヌドやキヌボヌドが機胜しおいないなどの誀動䜜が明らかになる堎合がありたす。モニタヌ画面が機胜しない堎合があるため、テスト結果はさたざたな高さの䞀連のビヌプ音ずしお報告されたす。それらが正確に䜕を意味するかは、マザヌボヌドのドキュメントに蚘茉されおいるはずです。叀いコンピュヌタヌは起動時にビヌプ音を鳎らすこずがよくありたす。これは、テスト結果を報告するBIOSプログラムです。゚ラヌ番号を瀺すために、远加のむンゞケヌタヌを䜿甚できる堎合がありたす。





すべおがうたくいった堎合、BIOSはOSブヌトロヌダヌを怜玢するプロセスを開始したす。これを行うために、圌はマザヌボヌドに接続されおいるすべおのハヌドドラむブのスキャンを開始したす。物理ディスク䞊のデヌタは、セクタヌず呌ばれる単䜍でアドレス指定され、通垞は512バむトですが、珟圚の暙準は4096バむトです。 Windowsむンストヌラヌは、特別なプログラムコヌドずパヌティションデヌタをディスクの最初のセクタヌに曞き蟌みたす。このセクタヌはマスタヌブヌトレコヌドず呌ばれたす。ディスクはパヌティションに分割され、独自のファむルシステムでフォヌマットされたす。最倧4぀のパヌティション、それぞれを拡匵できたす拡匵パヌティション、これは再垰的に4぀のセクションに分割でき、理論的にはその数に制限はありたせん。 BIOSがマスタヌブヌトレコヌドを芋぀けるずすぐに、そこからコヌドを読み取り、制埡をそこに移したす。このコヌドは、パヌティション䞊のデヌタを亀互に調べお、アクティブずしおマヌクされおいるものを芋぀けたす。これには、Windowsブヌトロヌダヌコヌドが含たれおいたすこれはC\ Windows \ System32のパヌティションではありたせん。このパヌティションはシステムパヌティションず呌ばれたす。原則ずしお、100MBを䜿甚し、ナヌザヌには衚瀺されたせん。このセクションの最初のセクタヌには、制埡が転送されるブヌトコヌドが栌玍されたす。これはボリュヌムブヌトセクタヌであり、その䞭のコヌドはBootmgrファむルを怜玢したす。このファむルからWindowsブヌトプロセスが開始されたす。 Bootmgrファむルは、Startup.comファむルずの間の単䞀のリンクを介しお䜜成されたす。Bootmgr.exe。



プロセッサは、「Real」ず呌ばれるモヌドで䜜業を開始したす。これは互換性モヌドであり、CPUは、仮想メモリをサポヌトしおいなかった叀い16ビットプロセッサず同じように動䜜し、1MBのメモリをアドレス指定できる20ビットアドレスバスを介しお物理メモリず盎接動䜜したした。単玔なMS-DOSプログラムはこのモヌドで実行され、拡匵子は.COMでした。 Startup.comBootmgrが最初に行うこずは、プロセッサを「保護」モヌドに切り替えるこずです。、ここで、保護ずは、プロセスを盞互に保護するこずを意味したす。このモヌドでは、仮想メモリず32ビットアドレスがサポヌトされおおり、4GBのRAMをアドレス指定するために䜿甚できたす。次のステップで、BootmgrはRAMの最初の16MBの仮想アドレステヌブルに入力し、仮想アドレスから物理アドレスぞの倉換をオンにしたす。このモヌドでは、Windowsが機胜したす。この段階ではOSサブシステムがただ䜜成されおいないため、BootmgrにはNTFSファむルシステムの独自の単玔で䞍完党な実装がありたす。そのおかげで、OSブヌトパラメヌタの蚭定を栌玍するBCDファむルブヌト構成デヌタが芋぀かりたす。BcdEdit.exeナヌティリティを䜿甚しお線集できたす。これらのBCD蚭定は、Windowsが䌑止状態にあり、Bootmgrがプログラムを開始するこずを瀺しおいる可胜性がありたす。WinResume.exeは、Hyberfil.sysファむルからメモリに状態を読み取り、ドラむバを再起動したす。BCDが耇数のオペレヌティングシステムがあるず蚀っおいる堎合、Bootmgrはそれらのリストを衚瀺し、ナヌザヌに遞択を求めたす。OSが1぀ある堎合、BootmgrはWinLoad.exeを起動したす。このプロセスは、Windowsを初期化する䞻な䜜業を実行したす。

  1. 適切なWindowsカヌネルバヌゞョンを遞択したす。実際にはNtOsKrnl.exeず呌ばれおいたすが、Windows10.exeず考えるこずができたす。どのバヌゞョンがありたすかりィキペディアによるず

    • ntoskrnl.exeは、シングルプロセッサのWindowsカヌネルです。PAEサポヌトなし
    • ntkrnlmp.exe英語のNTカヌネル、マルチプロセッサバヌゞョン-Windowsマルチプロセッサカヌネル。PAEサポヌトなし
    • ntkrnlpa.exe — Windows PAE.
    • ntkrpamp.exe — Windows PAE.


  2. HAL.dll (Hardware Abstraction Layer), CPU.
  3. vgaoem.fon
  4. , . National Language System.
  5. SYSTEMレゞストリをメモリにロヌドしたす。これには、ロヌドするドラむバに関する情報が含たれおいたす。すべおのドラむバヌに関する情報は、HKLM \ SYSTEM \ CurrentControlSet \ Services \にありたす。ロヌドする必芁のあるドラむバヌには、start = SERVICE_BOOT_START0キヌがありたす。レゞストリデバむスに぀いおは、別の蚘事で説明したす。
  6. ドラむバファむルが配眮されおいるパヌティションのファむルシステムドラむバをロヌドしたす。
  7. ドラむバをメモリにロヌドしたすが、埪環䟝存関係のため、ただ初期化されおいたせん。
  8. 最初のステップで遞択したWindowsカヌネルNtOsKrnl.exeを実行するためにCPUレゞスタを準備したす。


ドラむバがロヌドされるず、WinLoadはデゞタル眲名をチェックし、それらが䞀臎しない堎合は、青BSODたたは緑GSOD、むンサむダヌプレビュヌアセンブリの堎合の「死の画面」が衚瀺されたす。





UEFIで実行





UEFI



BIOSブヌト画面の䟋は30幎以䞊前からあり、その欠陥を修正するために、Intelは1998幎にIntel Boot Initiativeを䜜成し、埌にEFIに名前を倉曎し、2005幎にEFIフォヌラムに寄付したした。 BIOSのデメリット

•16ビットモヌドで

のみ機胜したす•1MbのRAMしかアドレス指定できたせん

•互換性の問題がしばしば発生し

たす•MBRは4぀のメむンディスクパヌティションのみに制限され

たす•OSディスクは2.2Tbを超えるこずはできたせん。

•OSブヌトロヌダヌを怜蚌するための機胜が非垞に制限されおいたす。

BIOSはUEFIに眮き換えられたした。実際、BIOSは32ビットず64ビットの䞡方で実行できるミニチュアOSです。互換性のために、オプションの互換性サポヌトモゞュヌルがありたす、蚭定に含たれ、BIOSを゚ミュレヌトしたす。





UEFIでは、ブヌトはプロセッサのネむティブビットネス32たたは64で発生し、すべおのメモリにアクセスでき、仮想メモリがサポヌトされ、セキュアブヌトが有効になり、OSのロヌドを開始する前にマルりェア察策を実行できたす。UEFIでのOSの起動順序

  1. ファヌムりェアの初期化ず起動、チップセットの起動。
  2. BIOSず同様のPOSTテスト
  3. EFIドラむバヌのロヌドずEFI適栌ブヌトディスクの怜玢
  4. EFIずいう名前のフォルダヌを怜玢したす。UEFI仕様では、FATファむルシステム甚にフォヌマットされた、100MB〜1GBのサむズ、たたはディスクサむズの1以䞋のEFIシステムパヌティション甚のパヌティションが必芁です。むンストヌルされおいる各Windowsには、このパヌティションに独自のディレクトリEFI \ Microsoftがありたす。

  5. UEFI NVRAM ( ) .
  6. EFI/Microsoft/Boot/BootMgrFw.efi.
  7. BootMgrFw.efi BCD, BCD. WinLoad.efi, C:\Windows\System32\winload.efi.


EFIシステムパヌティションの 内容を衚瀺するには、管理者暩限WinKey + X => Windows PowerShell管理者でコン゜ヌルを開き、mountvol Z/ s、Z、dirコマンドを実行したす。CD-ディレクトリを倉曎したす。

そのBIOSの察応から、UEFIのためのBOOTMGRずWinLoadコンポヌネント間の䞻な違いは、圌らが䜿甚しおいるこずであるEFIのAPIではなくBIOSの割り蟌みの、ずのフォヌマットMBR BIOSずEFIシステムパヌティションのブヌトパヌティションを非垞に異なっおいたす。



カヌネルの初期化



キヌボヌドのコンテキストでPCをロヌドするこずを怜蚎しおいるので、すべおの段階に集䞭するべきではないこずを思い出しおください。このプロセスのどこにキヌボヌドがあるかを理解する必芁があり、理解するために重芁な段階が匷調されおいたす。

前の段階で、WinLoad.exe / WinLoad.efiコンポヌネントが起動されたした。これは、WinLoadが䜜業䞭に収集したグロヌバル倉数ntKeLoaderBlockカヌネルモヌドメモリはすべおのプロセスで䜿甚可胜でブヌトパラメヌタを指定するこずにより、NtOsKrnl.exeを起動したす。これらが含たれたす

  1. SystemWindowsブヌトロヌダヌおよびBootC\ Windows \ System32ディレクトリぞのパス。
  2. WinLoadによっお䜜成された仮想メモリテヌブルぞのポむンタ
  3. 接続されたハヌドりェアの説明を含むツリヌ。HKLM\ HARDWAREレゞストリキヌを䜜成するために䜿甚されたす。
  4. ダりンロヌドしたレゞストリHKLM \ Systemのコピヌ
  5. Windowsの起動に参加しおいるロヌドされたただし初期化されおいないドラむバヌのリストぞのポむンタヌ。
  6. ダりンロヌドに必芁なその他の情報。


Windowsカヌネルは2段階で初期化されたす。これに先立っお、ハヌドりェア抜象化レむダヌが初期化されたす。これにより、特に、各CPUの割り蟌みコントロヌラヌが構成されたす。

同じ段階で、BSODのメッセヌゞを含む文字列がメモリに読み蟌たれたす。これは、萜䞋時にアクセスできないか、砎損しおいる可胜性があるためです。

  • カヌネル初期化の最初のフェヌズ

    1. Executive – , , . Windows SKU (Stock Keeping Unit), Windows 10 SKU — Home, Pro, Mobile, Enterprise, Education.
    2. Driver Verifier, .
    3. , API (memory services), .
    4. (kernel debugger) .
    5. Windows.
    6. Object Manager – . – . handle table, HWND .
    7. Security Reference Monitor .
    8. Process Manager . Idle System ( “Windows10.exe” NtOsKrnl.exe), , .
    9. User-Mode Debugging Framework.
    10. Plug and Play Manager. PnP – , . .


  • . 51 , :

    1. System (NtOsKrnl.exe) . . – 31.
    2. HAL .
    3. Windows Startup Screen, progress bar.
    4. Executive Semaphore, Mutex, Event, Timer.
    5. User-Mode Debugger .
    6. symbolic link \SystemRoot.
    7. NtDll.dll . Windows APIs.
    8. .
    9. Windows ALPC . named pipes Windows Communication Foundation .
    10. I/O Manager, . .

      Windows Management Instrumentation Event Tracing for Windows ( Windows Performance Analyzer). .
    11. SMSS.exe (Session Manager Sub System). , Windows.




– SMSS, CSRSS, WinInit



SMSS.exeはナヌザヌプロセスずは異なり、ネむティブプロセスであるため、远加の暩限が付䞎されたす。 SMSS.exeは、Windows APIをバむパスしおカヌネルず連携し、ネむティブAPIず呌ばれるものを䜿甚したす。 Windows APIは、ネむティブAPIのラッパヌです。 SMSS.exeは、最初にWindowsサブシステムCSRSS.exe-クラむアントサヌバヌランタむムサブシステムを起動し、レゞストリの初期化を終了したす。



SMSS.exeプロセスずスレッドはクリティカルずしおマヌクされおいたす。぀たり、゚ラヌなどが原因で予期せず終了した堎合、システムがクラッシュしたす。サブシステムず通信するために、たずえば、新しいセッションを䜜成するAPI呌び出しのために、SMSSはSmApiPortずいう名前のALPCポヌトを䜜成したす..。環境倉数がレゞストリからロヌドされ、Check Diskautochk.exe、これらのプログラムはレゞストリHKLM \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecuteに曞き蟌たれたすなどのプログラムが起動されたす。 SMSS.exeは、ナヌザヌセッションごずに起動されたす。仮想メモリメカニズムにより、各セッションには独自のグロヌバル倉数メッセヌゞキュヌなどがありたす。 Windowsには、スレッド、プロセス、およびセッションのコンテキストがありたす。各SMSS.exeは、サブシステムの独自のむンスタンスを開始したす。珟時点ではCSRSS.exeWindowsのみであり、過去にはOS / 2os2ss.exeおよびPOSIXpsxss.exeオペレヌティングシステムがサポヌトされおいたしたが、このアむデアは成功したせんでした。最初のSMSS.exeは、WinInit.exeプロセスを埅っおスリヌプ状態になりたす。残りのむンスタンスは、代わりにログむンUIを衚瀺するWinLogonプロセスを䜜成したす。



WinInit.exeは、グラフィカルシェルを䜜成するためのサブシステムを初期化したす-Windows Stationずデスクトップ。これは衚瀺されるデスクトップではなく、異なるWindowsの抂念です。次に、プロセスを開始したす。

  1. Services.exe - Services Control ManagerSCMは、AutoStartずしおマヌクされたサヌビスずドラむバヌを開始したす。サヌビスはsvchost.exeプロセスで開始されたす。tlist.exe -sパラメヌタヌを指定しお実行するず、各svchost.exe内のサヌビスの名前をコン゜ヌルに出力するtlist.exeずいうナヌティリティがありたす。
  2. LSASS.exe-ロヌカルシステムオヌ゜リティ。
  3. LSM.exe-ロヌカルセッションマネヌゞャヌ。


WinLogon.exe-資栌情報プロバむダヌをロヌドしたす。資栌情報プロバむダヌには、パスワヌド、Smartcard、PIN、HelloFaceなどがありたす。LogonUI.exeプロセスを生成したす。これにより、ナヌザヌに認蚌甚のむンタヌフェむスが衚瀺され、入力されたデヌタログむンずパスワヌド、PINが怜蚌されたす。



すべおがうたくいった堎合、WinLogonはレゞストリキヌHKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ WinLogon \ Userinitで指定されたプロセスを開始したす。デフォルトでは、これはUserInit.exeプロセスであり、次のようになりたす。

  1. レゞストリで指定されたスクリプトを実行したす。
    • HKCU \゜フトりェア\ポリシヌ\ Microsoft \ Windows \システム\スクリプト
    • HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows \ System \ Scripts
  2. User Profile Quota, %SystemRoot%\System32\Proquota.exe
  3. Windows, Explorer.exe. :
    • HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
    • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell


WinLogonは、ログむンしたナヌザヌに぀いおネットワヌクプロバむダヌに通知し、レゞストリに保存されおいるシステムディスクずプリンタヌを埩元しお接続したす。ネットワヌクプロバむダヌは、svchost.exeプロセスによっおホストされおいるシステムフォルダヌのmpr.dllファむルです。Windowsサヌビス。 プロセスツリヌは次のようになり、誰が誰を䜜成したかを確認できたすすべおのプロセスが衚瀺されおいるわけではなく、最新バヌゞョンのWindowsずは若干異なる堎合がありたす。









ここのキヌボヌドはどこにありたすか



起動時に、Windowsカヌネルはレゞストリからシステムバスコントロヌラヌに関する情報を読み取りたす。原則ずしお、これはPCIバスMSIの堎合は少ないであり、USB、PS / 2を含むI / Oポヌトコントロヌラヌが接続されたす。それに関する情報は、Windowsのむンストヌル䞭に蚘録されたす。システムはそのドラむバヌをロヌドし、すべおのポヌトを再垰的にバむパスし、ポヌトごずに独自のドラむバヌもロヌドしたす。ドラむバヌはドラむバヌノヌドに組み合わせるこずができたす。たずえば、キヌボヌドドラむバヌはPS2ポヌトドラむバヌに接続されたす。ただし、USBポヌトはもっず耇雑です。最初にポヌトドラむバヌ、次にHIDプロトコルを操䜜するためのドラむバヌ、そしおキヌボヌドだけです。



各ポヌトは、接続を監芖し、CPUずデバむス間で信号を送受信する独自​​のチップによっお制埡されたす。ラップトップでよく行われるように、サりスブリッゞチップセットがCPUに組み蟌たれおいないが、マザヌボヌド䞊に別個のチップずしお存圚する堎合は、サりスブリッゞずポヌトコントロヌラヌ間の信号ず蚀う方が正しいでしょう。制埡ポヌトチップには、割り蟌みコントロヌラヌPICたたはAPICを備えた専甚ラむンがあり、キヌボヌドからデヌタを読み取るなど、CPUに泚意を払うように芁求できたすPS / 2ポヌト、USBは別の話です。 OSはポヌトのドラむバヌをロヌドしおいるため、OSにコマンドを発行したり、デヌタを読み取ったり送信したりできたす。この䟋では、ドラむバヌはC\ Windows \ System32 \ i8042prt.sysからロヌドされたした。前の蚘事を思い出しおみたしょう。 PICがチップ䞊にある叀いコンピュヌタヌの堎合Intel 8259には15の割り蟌みラむンがあり、キヌボヌドはIRQ1ピン、IRQ0タむマヌに接続され、マりスはIRQ12に接続されたした。IRQ12は実際には2番目の8259チップの5番目のレッグであり、最初のコントロヌラヌのIRQ2ピンを介しお割り蟌みを倚重化したした。最新のPICは、割り蟌み信号甚に255ピンを持぀こずができたす。起動䞭、OSはAPIC / PICをプログラムしお、たずえばキヌボヌドたたはUSBポヌトから割り蟌みが到着したずきに特定の番号を返し、この番号によっおCPUは割り蟌みベクトルテヌブルで実行される関数を芋぀けたす。割り蟌み番号はHALずPlug'n'PlayManagerによっお決定されたす..。割り蟌みコントロヌラヌは、特定の順序でピンの信号を探したす。たずえば、無限ルヌプでは、1からMAX_PINたでのピンの電圧をチェックしたす。この順序によっお優先床が決たりたす。たずえば、キヌボヌドはマりスの前に衚瀺され、タむマヌはキヌボヌドの前に衚瀺されたす。割り蟌みコントロヌラヌの動䜜の特性に䟝存しないように、WindowsはIRQL割り蟌み芁求レベルでIRQ割り蟌み芁求の抂念を抜象化したす。割り蟌みコントロヌラヌに少なくずも15行たたは255行がある堎合、それらはすべおx86の堎合は32 IRQLに、x64およびIA64の堎合は15IRQLにマップされたす。
IRQLの優先順䜍ずはどういう意味ですか

  1. 高-システムがクラッシュするず、通垞はKeBugCheckEx関数が呌び出されたす。
  2. 電源障害-䜿甚されおいたせん。もずもずはWindowsNT甚に蚭蚈されたした。
  3. Interprocessor Interrupt – CPU , TLB cache, system shutdown, system crash (BSOD).
  4. Clock – , .
  5. Profile – real-time clock (local APIC-timer) kernel-profiling .
  6. Device 1 
 Device N – I/O. , DPC (Deferred Procedure Call), . Dispatch DPC
  7. Dispatch DPC — .
  8. APC — Asynchronous Procedure Call. WaitForSingleObject, Sleep .
  9. Passive/Low — User Mode.


すべおのナヌザヌプログラムはパッシブ/䜎0優先床で実行されるため、垞にナヌザヌモヌドでプログラミングしたこずがある堎合、IRQLに぀いお聞いたこずはありたせん。lshim優先床レベルに関するむベントキヌボヌドむベント、スレッドスケゞュヌラタむマヌがbで発生するずすぐに、プロセッサは䞭断されたスレッドの状態CPUレゞスタ倀を保存し、ディスパッチャ割り蟌み割り蟌みディスパッチャ、単なる関数を呌び出しお、IRQL優先床を䞊げたす。HALのKeRaiseIrqlAPIを介しお、割り蟌みのサヌビスルヌチン自䜓を盎接呌び出したす。その埌、CPUのIRQLはKeLowerIrql関数によっお前のレベルに䞋げられたす䞭断されたスレッドは、䞭断されたのず同じ堎所から凊理を開始したす。スレッドスケゞュヌラはこのメカニズムに基づいおいたす。特定の間隔タむムスラむスで、DPC /ディスパッチ2優先床の割り蟌みを生成し、その割り蟌みのサヌビスルヌチンで、特定のアルゎリズムに埓っお、実行甚の新しいスレッドを割り圓おるタむマヌを蚭定したす。



IRQLメカニズムは、ハヌドりェアではなく、ハヌドりェア抜象化レむダヌHAL.dllの゜フトりェアレベルで実装されたす。 Windowsシステムにはバスドラむバヌがありたす、バスに接続されおいるデバむスPCI、USBなどの存圚ず、各デバむスに割り圓おるこずができる割り蟌み番号を決定したす。バスドラむバは、この情報をプラグアンドプレむマネヌゞャに䌝達したす。プラグアンドプレむマネヌゞャは、各デバむスに割り圓おる割り蟌み番号をすでに決定しおいたす。さらに、PnP Mgr内の割り蟌みアヌビタヌPnP割り蟌みアヌビタヌは、IRQずIRQLの間のリンクを確立したす。



キヌボヌド割り蟌みが到着するず、珟圚実行䞭のスレッドこれはプログラムである可胜性がありたすがそれを凊理するために割り圓おられたす。割り蟌みディスパッチャは、CPUIRQLの優先床をDevice1-DeviceNレベルの1぀に䞊げたす。その埌、仮想メモリマネヌゞャは、ペヌゞがRAMにロヌドされおいない堎合、ペヌゞを芋぀けるこずができなくなりたすペヌゞ障害を凊理できなくなりたす。、スレッドスケゞュヌラはすべお䜎いIRQLで実行されるため、実行を䞭断できたせん。珟時点でのキヌボヌドドラむバの䞻なタスクは、受信したデヌタを読み取り、さらに凊理するために保存するこずです。デヌタはタむプ_DPCDeferred Procedure Callのオブゞェクトに曞き蟌たれ、DPCストリヌムのリストに保存されたすOSカヌネルでは、配列の代わりにリンクリストが䜿甚されたす。std :: list <DPC>のようなものが䜿甚されたす。すべおの倖郚デバむスからの割り蟌みが凊理されるずすぐに、スレッドのIRQLは、遅延プロシヌゞャDPCが凊理されるDPCレベルに䞋げられたす。キヌボヌドDPCハンドラヌコヌドは、キヌボヌドドラむバヌKbdclass.sysから関数を呌び出したす。



VOID KeyboardClassServiceCallback(
  _In_    PDEVICE_OBJECT       DeviceObject,
  _In_    PKEYBOARD_INPUT_DATA InputDataStart,
  _In_    PKEYBOARD_INPUT_DATA InputDataEnd,
  _Inout_ PULONG               InputDataConsumed
);


したがっお、キヌボヌドドラむバkbdclass.sysは、割り蟌みを介しおポヌトUSB、PS2からデヌタを受信し、WriteFileを介しおデヌタを曞き蟌みたす。これにより、Windowsカヌネル内のコンポヌネントが起動し、ReadFile APIを䜿甚しおデヌタを読み取り、キヌボヌドからのメッセヌゞをキュヌに远加したす。ファむルAPIを䜿甚しお、ドラむバヌからデヌタを読み取るこずができたす。この瞬間から、Windows入力スタックによるデヌタの凊理が開始されたす。これに぀いおは次の蚘事で詳しく説明したす。



PS2ポヌトを備えたPCがあり、カヌネルモヌドでWinDbgを䜿甚する方法を知っおいる堎合は、Idtず入力するず、キヌボヌドの割り蟌みハンドラヌを簡単に芋぀けるこずができたす。これにより、割り蟌みベクトルテヌブル党䜓が衚瀺されたす。..。䞭断はそれ自䜓をプログラムの過皋に抌し蟌みたす。ここでの単語ベクトルは、方向、プログラム実行の方向を意味したす。 WinDbgはWindowsデバッグ甚に特別に䜜成されたもので、最新バヌゞョンはWinDbgXず呌ばれたす。 Visual Studioに慣れおいる人を怖がらせるテキストベヌスのむンタヌフェむスを備えおいたすが、特にスクリプトの実行など、さらに倚くのオプションを提䟛したす。玫色のPS2ポヌト割り蟌みは赀で匷調衚瀺されおいたす。それを凊理する関数はI8042KeyboardInterruptServiceず呌ばれ、i8042prt.sysファむルにありたす。



BOOLEAN
I8042KeyboardInterruptService(
  IN  PKINTERRUPT Interrupt,
  IN  PVOID Context
  );

Routine Description:

    This is the interrupt service routine for the keyboard device when
    scan code set 1 is in use.

Arguments:

    Interrupt - A pointer to the interrupt object for this interrupt.

    Context - A pointer to the device object.

Return Value:

    Returns TRUE if the interrupt was expected (and therefore processed);
    otherwise, FALSE is returned.




ここで、割り蟌みハンドラヌはどこから匕数を取埗するのかずいう疑問が生じたす。誰が送信しおいたすか結局のずころ、CPUはそれに぀いお䜕も知りたせん。圌女のブレヌクポむントを蚭定するず、スタックの䞊䜍にいく぀かの機胜が衚瀺され、さらに驚きたした



。0kd> kC

呌び出しサむトの数

00i8042prt I8042KeyboardInterruptService

01 nt KiCallInterruptServiceRoutine

02 nt KiInterruptSubDispatch

03 nt KiInterruptDispatch

04 nt KiIdleLoop




説明は簡単です。プロセッサのIDTレゞスタに栌玍されおいる関数ではありたせん。䞊の写真に衚瀺されおいるのは、実際にはタむプ_KINTERRUPTのオブゞェクトです。..。割り蟌みテヌブルには、メモリ内の割り蟌みを説明するオブゞェクトを芋぀ける方法を知っおいる特別なアセンブリコヌドntKiIdleLoopが含たれおいたす。䜕がおもしろいですか

  1. .
  2. i8042prt!I8042KeyboardInterruptService, PS2 IN AL, 0x60 – 0x60 AL.
  3. dispatcher – №2 .
  4. CPU. CPU , .
  5. . , Windows . IRQL (Interrupt Request Level) – IRQ.


キヌボヌド割り蟌みハンドラヌが呌び出されるずすぐに、受信したデヌタがキヌボヌドドラむバヌに通知されたす。その埌、OSカヌネルに通知され、デヌタを凊理した埌、入力スタックに沿っおさらに送信され、応答するアプリケヌションに配信されるか、その前にハンドラヌに配信されたす。蚀語アゞア文字、自動修正、自動完了。

OSカヌネルはキヌボヌドドラむバヌず盎接察話したせん。この目的のためにPlug'n'PlayManagerが䜿甚されたす。このコンポヌネントは、デバむスが远加たたは削陀されたずきに提䟛されたコヌルバック関数を呌び出すIoRegisterPlugPlayNotificationAPIを提䟛したす。



USBに぀いお䞀蚀



USBポヌトの操䜜に粟通するには、その操䜜を説明する別の蚘事に加えお、WindowsでのHIDデヌタ凊理の説明が必芁になりたす。これは資料を非垞に耇雑にし、このトピックに関する優れた蚘事がすでにあるので、PS2はその単玔さのために完璧な䟋です。



USBは、キヌボヌド、カメラ、スキャナヌ、ペダル付きゲヌムホむヌル、プリンタヌなど、すべおのデバむスのナニバヌサルポヌトずしお䜜成されたした。さらに、ポヌトのネストをサポヌトしたす-USBマザヌボヌド=> USB付きモニタヌ=>マりスが接続されおいるUSB付きキヌボヌド、フラッシュドラむブハヌドドラむブが接続されおいるUSBハブ。 USB 2.0ピンを芋るず、PS2のような特定のデヌタの転送甚に蚭蚈されおいないこずがわかりたす。それらは4぀だけです-デヌタビットを送信するためのツむストペアずプラスずマむナスの電力。





USB 2.0



ケヌブルは、5぀の远加ピンを䜿甚しおUSB3.0に高速に接続したす。ご芧のずおり、同期甚のCLOCKラむンがないため、デヌタ転送ロゞックはより耇雑です。比范のために巊のUSB2.0ず右のUSB3.0。

すべおのデヌタは、HIDHuman Interface Deviceプロトコルを介しお送信されたす。このプロトコルは、圢匏、察話ずデヌタ転送の順序、およびその他すべおを蚘述したす。USB 2.0暙準は650ペヌゞ、デバむスマりス、キヌボヌドなどの操䜜を説明するHIDクラス仕様曞は97ペヌゞです。USBを䜿甚する堎合は、それらを調べるこずをお勧めしたす。



たず、接続されたデバむスはそれ自䜓に぀いお通知する必芁がありたす。このため、Plug'n'Playマネヌゞャヌがレゞストリ内の情報を怜玢し、ドラむバヌをロヌドしお接続するためのデバむスIDずメヌカヌIDを瀺すいく぀かのデヌタ構造を送信したす。 USBデバむスはパッシブです。ホストは、特定の間隔でデヌタ自䜓の存圚を確認する必芁がありたす。ポヌリングレヌトずデヌタパケットサむズは、USBデバむス蚘述子の1぀で指定されたす。最倧パケットサむズは64バむトで、抌されたキヌに関する十分な情報です。



WindowsにはHIDサポヌトが組み蟌たれおいたすが、HIDドラむバヌはプロトコルでサポヌトされおいるすべおのスクリプトを凊理できる必芁があるため、PS2ポヌトドラむバヌをキヌボヌドドラむバヌにリンクするほど簡単ではありたせん。デヌタプロバむダヌPS2、USB、リモヌトデスクトップポヌト、たたは仮想マシンに関係なく、ドラむバヌノヌドの最䞊郚にはKbdclassがあり、そこからOSカヌネルが情報を受信したす。キヌボヌド接続通知はPlug'n'Play Managerを介しお凊理されるため、どのポヌトたたはデバむスデヌタ゜ヌスが䜿甚されおいるかはWindowsカヌネルには関係ありたせん。



パヌト1-OSずコンピュヌタヌの基本

パヌト2-PS2ポヌトを介したマザヌボヌドずキヌボヌドの動䜜



All Articles