Hardware Security · GPU-UNLOCK TENSOR CORE 2× FULL-RATE SEC2 V67 ROP + PCIe FLR Linux vs UEFI

คู่มือและระบบจำลองสถาปัตยกรรม GPU-UNLOCK ครบวงจร

เจาะลึกกระบวนการปลดล็อกความเร็ว Tensor Core (FP16 / BF16 / TF32) จาก Half-Rate 50% สู่ Full-Rate 100% สำหรับงาน Local AI โดยจำลองการทำงานระดับฮาร์ดแวร์ 4 ช่วง 9 ขั้นตอน พร้อมวิเคราะห์สถาปัตยกรรม Linux Kernel เทียบกับ Windows UEFI

RTX 3090 Ti (BF16)
87.5 → 157.4 TFLOPS
+80% FP32 Accumulate
RTX 3090 Ti (TF32)
42.6 → 82.6 TFLOPS
+94% Dense Matrix Math
RTX 4090 (Peak MMA)
165 → 329 TFLOPS
2× Full Tensor Issue Rate
Target Selector
SS0 = 0x88888888
PLM @ 0x00823804 Unlocked

แผนผังภาพรวมการทำงาน 4 ช่วง (Process Lifecycle)

คลิกที่ช่วงการทำงานเพื่อกระโดดไปยังขั้นตอนจำลองระดับเคอร์เนลและฮาร์ดแวร์ได้ทันที (รองรับปุ่มลูกศรซ้าย/ขวาบนคีย์บอร์ด)

Interactive Jump
PHASE 1 STEP 1 / 9

1. โหลดโมดูลใน initramfs & ค้นหาการ์ดจอ

kernel/gpu_unlock/main.c : gpu_unlock_init()

STATE: MODULE_INIT
คอมพิวเตอร์ (Host Ring 0)
1. โมดูล gpu_unlock.ko initramfs

main.c / unlock_610.c

สแกนหา PCI ID การ์ดจอที่รองรับ
2. Coherent DMA (32-bit)
work->meta: GspFwWprMeta (256B)
work->buffer: V67 ROP (0xfa00 B)
work->fwsec & booter_buf
work->pages[]: Radix3 Table
3. ไดรเวอร์แท้ nvidia.ko Stock Driver
รอรับไม้ต่อหลังทำ PCIe FLR เสร็จ…
PCIe BAR0 / DMA SCAN PCI
ระบบควบคุมในการ์ดจอ (VBIOS, GSP & SEC2)
4. VBIOS PROM (0x300000) Board ROM

เก็บเฟิร์มแวร์ FWSEC-FRTS และฟิวส์ (0x824140)

5. ชิป GSP Falcon (0x110000) falcon.c

รัน FWSEC-FRTS โหมด L3 เพื่อเปิดตู้เซฟ WPR2 บน VRAM

สถานะ: GFW_BOOT Ready
6. ชิปยาม SEC2 Falcon (0x840000) Level 3 HS

รับ WprMeta ผ่าน Mailbox โดน V67 Overflow แล้วรัน ROP ปลดล็อก PLM

สถานะ: Idle (รอคำสั่ง)
VRAM & เรจิสเตอร์เป้าหมาย
7. ตู้เซฟ WPR2 ใน VRAM

ตำแหน่ง: ท้ายสุด 256 MB ของ VRAM

WPR2 (0x1fa828): DOWN (0x0)
8. เรจิสเตอร์ PLM & SS0/SS1
WPR_CFG_PLM (0x001fa7cc)
Locked (Level 3 Only)
GU_FEAT_PLM (0x00823804)
0xffffff8f (L3 Write Only)
GU_FEAT_SS0 (0x0082381c)
0x00000001 (Half-Rate 50%)
GU_FEAT_SS1 (0x00823820)
0x00000001 (Half-Rate 50%)
คำอธิบายการทำงานในขั้นตอนนี้โดยละเอียด

ลำดับการเรียกฟังก์ชัน (Call Stack)
โค้ดภาษา C ที่ทำงานจริง
main.c 

          


          

            

               ถอดรหัสบิตเรจิสเตอร์สด
            

            

              

                GU_FEAT_PLM (0x823804)
                0xffffff8f
              

              
Bits[7:4] WRITE = 1000 (เขียนได้เฉพาะ L3 Heavy-Secure)

            

            

              

                GU_FEAT_SS0 (0x82381c)
                0x00000001
              

              
ค่าเริ่มต้น GA102 (0x00000001): บิต Override ปิดอยู่ จึงติดเพดาน Half-Rate 50%

            

          

        

      


      
      
      
      

        

          

            

              
 ผ่าโครงสร้างหน่วยความจำ SEC2: ทำไมส่งลายเซ็น 64,000 ไบต์ แล้วปลดล็อกการ์ดจอได้?

              
กดเลือกจังหวะการทำงานทั้ง 3 ระยะ เพื่อดูการล้นของข้อมูลในหน่วยความจำ DMEM และการกระโดดรันชุดคำสั่งใน IMEM

            

            

              
              
              
            

          


          

            
            

              

                หน่วยความจำภายในชิปความปลอดภัย SEC2 Falcon (Level 3 Heavy-Secure)
                PHASE 1: NORMAL SIGNATURE BUFFER
              


              

                

                  DMEM (เก็บบัฟเฟอร์และ Call Stack ในพื้นที่เดียวกัน)
                  0x0000 .. 0xffff (64 KB)
                

                

                  

                    
OS / Data

                    
0x0000..0x10ff

                  

                  

                    
Signature Buffer

                    
รับลายเซ็นปกติ (~384–4096 B)

                  

                  

                    
Free Space

                    
พื้นที่ว่าง

                  

                  

                    
Call Stack (ปกติ)

                    
0xf93c .. 0xf9f4

                  

                

              


              

                

                  ภาพขยาย Call Stack ที่ออฟเซ็ต 0xf93c – 0xf9f4 (สร้างโดย gu_payload_build() แบบ 6-Write Chain):
                

                

                  

                    Offset 0xf944 / 0xf948 (Slot 1):
                    ตัวแปรท้องถิ่นปกติ
                  

                  

                    Offset 0xf95c / 0xf960 (Slot 2):
                    ตัวแปรท้องถิ่นปกติ
                  

                  

                    Offset 0xf950 .. 0xf9c8 (6× Write):
                    Return Address เดิมของ Booter
                  

                  

                    Offset 0xf9e0 .. 0xf9f4 (Cleanup):
                    Stack Frame ของฟังก์ชันแม่
                  

                

              


              

                

                  หน่วยความจำคำสั่ง IMEM ของ GA102 Booter (โค้ดที่ฮาร์ดแวร์การ์ดจอถอดรหัสวางเรียงพร้อมรันแล้ว):
                

                

                  

                    
Canary @ 0x6140 & Epilogue @ 0x0686

                    
ผ่านด่านตรวจ Canary (0x1149) & ป๊อป r0=Addr, r1=Val

                  

                  

                    
Gadget @ 0x1110 (reg_write_indirect)

                    
เขียน MEM[r0] = r1 (สิทธิ์ L3 วนได้ 6 รอบ/ครั้ง)

                  

                  

                    
Cleanup @ 0x576b → 0x84c8 → 0x0d52 → 0x81ee

                    
ทำ SE/CSB Handshake เปิด RESET_PLM & Halt สะอาด

                  

                

              

            


            
            

              

                
1. สภาวะปกติ: SEC2 Booter โหลดลายเซ็นมาตรวจสอบ

                

              


              

                

                  
                  ทำไมเฟิร์มแวร์ที่เข้ารหัสไว้ ถึงถูกนักวิจัยแกะได้?
                

                
    
                  
  • ความพลาดที่ 1 (แนบอิมเมจดีบักติดมา): ในซอร์สโค้ดไดรเวอร์ NVIDIA ยุคแรก นอกจากก้อนเฟิร์มแวร์ใช้งานจริง (IMAGE_PROD) แล้ว ยังเผลอแนบก้อนเฟิร์มแวร์สำหรับดีบัก (BINDATA_LABEL_IMAGE_DBG_data[]) ติดมาด้วย
    • 
                  
  • ความพลาดที่ 2 (ล็อกด้วยกุญแจสาธารณะ): ไฟล์ IMAGE_DBG ถูกเข้ารหัสด้วย Test Key Index 37 ที่ทราบวิธีถอดรหัส นักวิจัยจึงแกะดูโค้ดข้างในได้ทุกบรรทัดเพื่อค้นหา ROP Gadgets
    • 
                  
  • จังหวะทำงานจริง: เวลาชิปยาม SEC2 โหลดไฟล์จริง (IMAGE_PROD) ตัวการ์ดจอจะถอดรหัสโค้ดออกมาวางใน IMEM ก่อนเริ่มรัน ดังนั้นเมื่อเกิด Stack Overflow โค้ดข้างในจึงถูกถอดรหัสพร้อมให้กระโดดไปรันตามออฟเซ็ตได้ทันที
    • 
                

              

            

          

        

      


      
      
      
      

        

          

            

              
 จำลองความเร็ว Tensor Core: ทำไมสาย Local AI ถึงปลดล็อกเรจิสเตอร์ SS0 & SS1?

              
กดสลับโหมดเพื่อเปรียบเทียบความเร็วการคูณเมทริกซ์หนาแน่น (Dense GEMM with FP32 Accumulation)

            

            

              
              
            

          


          

            
            

              
ผลทดสอบคำนวณจริงบน RTX 3090 Ti & RTX 2060 (FP32 Accumulate)


              

                

                  BF16 (FP32 Accum) — Flux, Wan2.2, LLM Fine-tune
                  87.50 TFLOPS (Half-Rate 50%)
                

                

                  

                

              


              

                

                  FP16 (FP32 Accum) — SDXL, ComfyUI, PyTorch AMP
                  87.46 TFLOPS (Half-Rate 50%)
                

                

                  

                

              


              

                

                  TF32 (TensorFloat-32) — งานเทรนโมเดลความละเอียดสูง
                  42.58 TFLOPS (Half-Rate 50%)
                

                

                  

                

              


              

                

                  RTX 2060 (Turing TU106): FP16 (FP32 Accumulate)
                  ~26.0 TFLOPS (Half-Rate 50%)
                

                

                  

                

              

            


            
            

              

                

                  ความลับของตัวเลข 0x88888888 ในเรจิสเตอร์ SS0
                

                

                  เรจิสเตอร์ FEAT_OVR_SM_SPD (0x0082381c) ขนาด 32 บิต แบ่งเป็น 8 ช่อง (ช่องละ 4 บิต) คุมอัตราการยิงคำสั่ง DP, FFMA, FMLA16, FMLA32 และ IMLA0–3:
                


                

                  

                    
บิตที่ 3 (Override Enable)

                    
0 = ใช้ค่าอั้นจากโรงงาน

                    
1 = บังคับใช้ค่าที่เราตั้งเอง

                  

                  

                    
บิตที่ 2:0 (Speed Rate)

                    
000 = Full Rate (100%)

                    
001 = Half Rate (50%)

                    
010 = 1/4 Rate (25%)

                  

                

              


              

                เลขฐานสิบหก 8 คือ 1000 ในฐานสอง (เปิด Override + เลือก Full Rate 100%) เมื่อเขียน 0x88888888 ลง SS0 และ 0x8 ลง SS1 (IMLA4) จึงปลดล็อกทุกช่องคำนวณพร้อมกันโดยผลลัพธ์ตรงระดับบิต (Bit-Identical) 100%
              

            

          

        


        
        

          

            

              
 ผลทดสอบ BF16 (FP32 Accumulation) จากผู้ใช้จริงตามสเปกไฟเดิมโรงงาน

              
อ้างอิงจากรายงานผลการทดสอบในโปรเจกต์ gpu-unlock (Stock Power Limits)

            

          


          

            

              
                

                  รุ่นการ์ดจอ (GeForce RTX)
                  ก่อนปลดล็อก (BF16 Stock)
                  หลังปลดล็อก (BF16 Unlocked)
                  อัตราที่เพิ่มขึ้น
                

              
              
                

                  RTX 3060 12 GB
                  27 TFLOPS
                  51 TFLOPS
                  +87%
                

                

                  RTX 3060 Ti / RTX 3070
                  37 / 40 TFLOPS
                  68 / 72 TFLOPS
                  +81% – +82%
                

                

                  RTX 3080 10 GB / RTX 3090
                  65 / 75 TFLOPS
                  113 / 125 TFLOPS
                  +65% – +73%
                

                

                  RTX 3090 Ti (450 W)
                  88 TFLOPS
                  157 TFLOPS
                  +80%
                

                

                  RTX 4070 Ti / RTX 4080
                  81 / 104 TFLOPS
                  150 / 193 TFLOPS
                  +84% – +87%
                

                

                  RTX 4090 (Peak MMA Rate)
                  165 TFLOPS
                  329 TFLOPS
                  +100% (ติดเพดาน Power Limit เมื่อ GEMM ใหญ่)
                

              
            

          


          

            

              
 งาน AI ที่เร็วขึ้นชัดเจน (+25% ถึง +90%)

              
    
                
  • LLM Prompt Prefill / TTFT บน vLLM, PyTorch (+25–55%)
    • 
                
  • LoRA & Full Fine-tuning ใน BF16 / FP16 (+25–50%)
    • 
                
  • FlashAttention / SDPA Kernels (+50–60%)
    • 
                
  • Image Gen: SDXL, SD 1.5, Krea, DiT (เช่น Flux) ใน ComfyUI (+30–55%)
    • 
                
  • Video Gen: Wan 2.2 BF16 Compute (+15–20%)
    • 
              

            


            

              
 งานที่เปลี่ยนแปลงเล็กน้อย (0% ถึง 15%)

              
    
                
  • LLM Token Decode (คอขวดอยู่ที่ VRAM Bandwidth ไม่ใช่ Tensor Core)
    • 
                
  • การรัน Quantized GGUF บน llama.cpp / Ollama (เห็นผลเฉพาะ Long Context)
    • 
                
  • โมเดล Quantization ระดับต่ำ (INT8, FP8, INT4)
    • 
              

            


            

              
 งานที่ไม่เปลี่ยนแปลง (0%)

              
    
                
  • การเล่นเกมทั่วไป (ใช้ FP32 Shader / RT Core / Rasterization)
    • 
                
  • การเข้ารหัสและตัดต่อวิดีโอทั่วไป (ใช้ NVENC / NVDEC)
    • 
                
  • งานคำนวณ CUDA FP32 มาตรฐานที่ไม่ได้เรียก Tensor Core
    • 
              

            

          

        

      


      
      
      
      

        

          

            

              
 เปรียบเทียบสถาปัตยกรรม: gpu-unlock (Linux) vs Windows-GPU-UNLOCK

              
ทั้งสองโปรเจกต์ใช้เทคนิค V67 ROP เจาะ SEC2 เหมือนกัน แต่ Linux รันเป็น Kernel Module ใน initramfs ส่วน Windows ต้องถอยไปรันในชั้น UEFI Pre-Boot

            

            

              
              
            

          


          

            

              เส้นทางการบูตและการปลดล็อกบน Linux
              RECOMMENDED FOR LOCAL AI
            


            


            

          

        


        
        

          

            
 4 สาเหตุเชิงวิศวกรรม: ทำไมบน Linux ถึงง่ายและเสถียรกว่าบน Windows อย่างมหาศาล?

          


          

            

              

                สาเหตุที่ 1
                การตรวจสอบลายเซ็นไดรเวอร์ (WDDM & WHQL vs Open Kernel)
              

              

                บน Linux คุณสามารถบรรจุโมดูล gpu_unlock.ko ลงใน initramfs ให้ทำงานก่อน nvidia.ko ได้โดยตรง ส่วนบน Windows ติดระบบบังคับลายเซ็นไดรเวอร์ WHQL ของ Microsoft และโครงสร้าง WDDM จึงแทรกตัดหน้า nvlddmkm.sys ไม่ได้ ต้องถอยออกไปรันเป็นไฟล์ .efi ก่อนบูตเข้า Windows
              

            


            

              

                สาเหตุที่ 2
                วิกฤตสัญญาณภาพหลุดเมื่อรีเซ็ตการ์ดจอ (UEFI GOP Destruction)
              

              

                ทันทีที่สั่ง PCIe FLR โปรโตคอลแสดงผลภาพของไบออส (GOP — Graphics Output Protocol) จะพังทันที! Linux Framebuffer รับมือการส่งต่อไดรเวอร์ได้ราบรื่นจอไม่ดับ แต่ Windows Boot Manager ต้องการ GOP ตลอดเวลา จึงเสี่ยงเกิดจอดำหรือค้าง ต้องพึ่งโหมด Headless หรือต่อสายจอผ่าน iGPU
              

            


            

              

                สาเหตุที่ 3
                การตื่นจากโหมดประหยัดพลังงาน (Sleep / Suspend / D3cold)
              

              

                เมื่อเครื่องเข้าโหมด Sleep ไฟเลี้ยงการ์ดจอจะถูกตัด ทำให้เรจิสเตอร์ SS0/SS1 ถูกรีเซ็ตกลับเป็น 50% บน Linux โมดูลลงทะเบียน PM_POST_SUSPEND คอยยิงปลดล็อกซ้ำอัตโนมัติทันทีที่ตื่น แต่บน Windows แอป UEFI รันได้แค่ตอนเปิดเครื่อง หากเผลอ Sleep ความเร็วจะหลุดทันทีจนกว่าจะรีบูตใหม่
              

            


            

              

                สาเหตุที่ 4
                ความยืดหยุ่นฮาร์ดแวร์ vs การล็อก Machine Profile ตายตัว
              

              

                บน Linux สแกน PCI Device ID แบบไดนามิก ใช้ได้กับทุกเมนบอร์ดด้วยคำสั่ง make install ส่วน Windows UEFI ต้องผูก Machine Profile ตายตัว (รุ่นเมนบอร์ด + เวอร์ชันไบออส + รุ่นย่อยการ์ดจอ) ต้องแบ่งพาร์ติชัน ESP แยก ปิด Secure Boot และปิด BitLocker
              

            

          

        


        
        

          

            
 ตารางเปรียบเทียบเชิงสถาปัตยกรรม (Linux vs Windows)

          


          

            

              
                

                  มิติการเปรียบเทียบ
                   gpu-unlock (Linux)
                   Windows-GPU-UNLOCK
                

              
              
                

                  ตำแหน่งที่โค้ดทำงาน
                  Linux Kernel Module (gpu_unlock.ko) ใน initramfs
                  UEFI Application (.efi) ในพาร์ติชัน ESP แยก
                

                

                  ช่วงเวลาที่เริ่มทำงาน
                  Early OS Boot ก่อนโมดูล nvidia.ko โหลด
                  Pre-Boot Firmware Stage ก่อนเข้า bootmgfw.efi
                

                

                  ความยากในการติดตั้ง
                  ง่าย: make install + เพิ่มพารามิเตอร์เคอร์เนล
                  ซับซ้อนสูง: แบ่ง ESP, ปิด BitLocker, คอมไพล์โปรไฟล์เฉพาะเครื่อง
                

                

                  การจัดการสัญญาณภาพ (GOP)
                  ราบรื่น สลับไดรเวอร์ได้โดยจอไม่ดับ
                  GOP พังหลัง FLR ต้องใช้โหมด Headless หรือต่อ iGPU
                

                

                  การรองรับโหมด Sleep
                  รองรับอัตโนมัติผ่าน PM_POST_SUSPEND
                  ไม่รองรับ ตื่นมาความเร็วลดเหลือ 50% ต้องรีบูตเครื่อง
                

                

                  ความเร็ว AI หลังปลดล็อก
                  Full-Rate 100% (สูงสุด 2× TFLOPS)
                  Full-Rate 100% (สูงสุด 2× TFLOPS เท่ากัน)
                

              
            

          

        

      


      
      
      
      

        

          

            

              
 สถานะการรองรับแต่ละสถาปัตยกรรมการ์ดจอ NVIDIA

              
เปรียบเทียบโครงสร้างบูตของเฟิร์มแวร์ตั้งแต่ยุค Turing จนถึงการรื้อระบบใหม่เป็น RISC-V FSP ใน Blackwell

            

          


          

            

              

                RTX 20 (Turing)
                TU102–TU106
              

              

                สถานะ: Experimental

                ปลดล็อก FP16 (FP32 accumulate) บน RTX 2060–2080 Ti และ Titan RTX เร็วขึ้น 2 เท่า (เรจิสเตอร์ FEAT ที่ 0x409650) ใช้ชุด gsp_tu10x.bin, booter_load_tu102.bin และ sec2_bl_tu102.bin
              

            


            

              

                RTX 30 (Ampere)
                GA102–GA106
              

              

                สถานะ: Stable (100+ Reports)

                รองรับสมบูรณ์ทั้ง RTX 3050 ถึง 3090 Ti และ RTX 3070/3080 Laptop ปลดล็อกทั้ง FP16, BF16 และ TF32 เต็มสปีดด้วย booter_load_ga102.bin โดยไม่ต้องแฟลช VBIOS
              

            


            

              

                RTX 40 (Ada)
                AD102–AD107
              

              

                สถานะ: Experimental

                ใช้ชุด booter_load_ad102.bin ปลดล็อกอัตราคำสั่ง MMA ของ RTX 4060–4090 / 4090 D และ RTX 4050/4060/4090 Laptop เทียบเท่าการ์ดตระกูล RTX Ada Workstation
              

            


            

              

                RTX 50 (Blackwell)
                GB202+
              

              

                สถานะ: ไม่รองรับ

                ยกเลิกระบบ booter_load เดิม เปลี่ยนเป็นสถาปัตยกรรม FMC + FSP (RISC-V) ที่มีฮาร์ดแวร์กั้นหน่วยความจำและไม่มีไฟล์ IMAGE_DBG หลุดออกมา
              

            

          

        


        
        

          

            

              
 มุมมองด้าน Cybersecurity: การยกระดับสิทธิ์สู่ Level 3 (Threat Model & Mitigations)

              
วิเคราะห์ความเสี่ยงเชิงรุกหากผู้โจมตีได้สิทธิ์ Ring 0 / Root บนเครื่องโฮสต์ และกลไกป้องกันระดับฮาร์ดแวร์ยุคใหม่

            

          


          

            

              

                
                ความเสี่ยงเชิงรุก (เมื่อผู้โจมตียึดสิทธิ์ Ring 0 บนเครื่องได้ก่อน)
              

              
    
                
  • 1. GPU-Assisted Rootkit ในเขต WPR2: หากใช้ ROP ปลดล็อก GU_WPR_PLM_OFFSET (0x001fa7c4) ผู้โจมตีอาจแก้ไขโค้ด GSP-RM ในเขตหวงห้าม WPR2 แล้วล็อก PLM กลับ ทำให้ EDR หรือเครื่องมือสแกนฝั่ง Host CPU (Level 0) อ่านหน่วยความจำส่วนนั้นไม่ได้ (ได้ค่า 0xbadf0000)
    • 
                
  • 2. Cloud Multi-Tenant Isolation Risk: ในสภาพแวดล้อม GPU Passthrough ที่แชร์ฮาร์ดแวร์โดยไม่ตัดไฟรีเซ็ตเต็มรูปแบบ การแก้ค่า WPR_PLM หรือ FBPA_PLM จึงเป็นเหตุผลว่าทำไมผู้ให้บริการ Cloud ต้องบังคับแยกกั้นหน่วยความจำ (Hardware Isolation) ด้วย IOMMU และรีเซ็ตการ์ดจอระดับบอร์ด
    • 
                
  • 3. คำเตือนด้าน Supply Chain: โปรเจกต์ต้นฉบับบน Linux แจกเป็นซอร์สโค้ดเปิด (GPL-2.0) เท่านั้น ไม่มีไฟล์ .exe สำเร็จรูป การดาวน์โหลดตัวติดตั้งไม่ทราบแหล่งที่มาบน Windows มีความเสี่ยงสูงต่อมัลแวร์ระดับ Bootkit
    • 
              

            


            

              

                
                กำแพงป้องกันของฮาร์ดแวร์และระบบปฏิบัติการ (Defense-in-Depth)
              

              
    
                
  • 1. กำแพง IOMMU (Intel VT-d / AMD-Vi / Kernel DMA Protection): บล็อกไม่ให้เอนจิน Falcon บนการ์ดจอใช้ท่อ DMA อ่านหรือเขียน System RAM ของเครื่องโฮสต์ได้ตามใจชอบ (เข้าถึงได้เฉพาะเพจที่เคอร์เนลเปิดให้ผ่าน dma_alloc_coherent เท่านั้น)
    • 
                
  • 2. ฮาร์ดแวร์ฟิวส์ป้องกันการถอยเวอร์ชัน (Anti-Rollback Fuse @ 0x00824140): เรจิสเตอร์ GU_FUSE_SEC2_UCODE1 ตรวจเลขเวอร์ชันขั้นต่ำของไมโครโค้ดในซิลิคอน หากฟิวส์ถูกเผายกระดับเวอร์ชันแล้ว ชิปจะปฏิเสธ Booter รุ่นเก่าที่มีช่องโหว่ทันที
    • 
                
  • 3. Secure Boot & Kernel Lockdown: การเปิด UEFI Secure Boot ร่วมกับ Kernel Lockdown ป้องกันไม่ให้ผู้ไม่ได้รับอนุญาตโหลดโมดูลเคอร์เนลที่ไม่ได้เซ็นรับรอง (Unsigned Module) เข้าสู่ Ring 0
    • 
              

            

          

        

      


      
      
      
      

        

          
          

            

              

                
 พจนานุกรมคำศัพท์เทคนิคสำคัญ

                
ค้นหาคำศัพท์เรจิสเตอร์และสถาปัตยกรรมภายในตัวการ์ดจอ

              

            


            

              
              
            


            

              

                SS0 / SS1 (Speed Selectors @ 0x82381c, 0x823820): เรจิสเตอร์ตัวเลือกอัตราความเร็วคำสั่ง SM (บน Turing อยู่ที่ 0x409664, 0x40966c) เปลี่ยนจาก 0x1 (ครึ่งสปีด) เป็น 0x88888888 และ 0x8 (เต็มสปีด 100%)
              

              

                PLM (Privilege Level Mask @ 0x823804): บิตมาสก์ควบคุมสิทธิ์อ่าน/เขียนเรจิสเตอร์ (Level 0 = Host CPU, Level 3 = Heavy-Secure Falcon) ต้องแก้เป็น 0xffffffff เพื่อให้ Host เขียนค่าลง SS0/SS1 ได้
              

              

                BAR0 (Base Address Register 0): หน้าต่างหน่วยความจำ MMIO บนสล็อต PCIe ที่เปิดให้เคอร์เนลของ CPU อ่านและเขียนเรจิสเตอร์ควบคุมของการ์ดจอ
              

              

                GSP & SEC2 (Falcon Engines): ไมโครโปรเซสเซอร์ภายในชิปการ์ดจอ โดย GSP ดูแลการจัดการระบบ และ SEC2 ทำงานที่สิทธิ์สูงสุด Level 3 เพื่อตรวจลายเซ็นเฟิร์มแวร์
              

              

                IMEM & DMEM: หน่วยความจำความเร็วสูงภายในชิป Falcon แยกเป็น IMEM เก็บชุดคำสั่ง และ DMEM เก็บข้อมูลรวมถึง Call Stack ในพื้นที่ 64 KB เดียวกัน
              

              

                WPR2 (Write Protected Region 2): พื้นที่นิรภัยท้าย VRAM ที่สร้างโดย FWSEC-FRTS เพื่อเก็บเฟิร์มแวร์และป้องกันไม่ให้ CPU ฝั่งโฮสต์แอบแก้ไข
              

              

                PCIe FLR (Function Level Reset): คำสั่งรีเซ็ตเฉพาะฟังก์ชัน PCIe ช่วยล้างสถานะ GSP, SEC2 และ WPR2 ให้สะอาดก่อนส่งให้ nvidia.ko โดยค่า SS0/SS1 ยังคงอยู่ครบ
              

              

                GOP (Graphics Output Protocol): ไดรเวอร์แสดงผลภาพระดับ UEFI Pre-Boot ซึ่งจะหยุดทำงานทันทีเมื่อการ์ดจอถูกรีเซ็ตด้วย PCIe FLR
              

            

            
          


          
          

            

              

                

                  
 สารบัญไฟล์ซอร์สโค้ดหลักในโปรเจกต์

                  
โครงสร้างโมดูลเคอร์เนลและเฟิร์มแวร์ที่ใช้ทำงานจริง

                

              


              

                

                  
kernel/gpu_unlock/main.c

                  
จุดเริ่มต้นโมดูล gpu_unlock_init() สั่งปลดล็อกการ์ดจอทุกใบแบบขนาน และลงทะเบียน pm_nb ดักปลดล็อกซ้ำหลังตื่นจาก Sleep

                

                

                  
kernel/gpu_unlock/unlock_610.c

                  
หัวใจหลัก gpu_unlock_610_unlock() ควบคุมครบทั้ง 9 ขั้นตอน: _claim, _layout, _dma, _fwsec, run_privileged_writes, run_host_writes, _reset, _unwind

                

                

                  
kernel/gpu_unlock/recipes.c & payload.c

                  
เก็บตาราง PCI IDs, ชุด ROP Gadgets แบบ 6-Write (ga102_words, ad102_v67_words, tu102_words), เรจิสเตอร์ PLM, ค่า SS0/SS1 และตัวสร้างบัฟเฟอร์ 0xfa00 ไบต์

                

                

                  
kernel/gpu_unlock/falcon.c, vbios_610.c, prep_610.c

                  
ควบคุมเอนจิน Falcon ทั้ง GSP และ SEC2, แกะ FWSEC จาก VBIOS ROM, สร้างตารางเพจ Radix3 และแพ็ก GspFwWprMeta

                

              

            


            

              

                

                  
 ตัวอย่างคำสั่งติดตั้งบน Linux (อ้างอิงเอกสารต้นฉบับ)

                  
รองรับตระกูล Debian/Ubuntu, Arch/CachyOS และ Fedora/RHEL

                

              


              
git clone https://github.com/Zagitta/gpu-unlock
cd gpu-unlock
make install

# เพิ่ม gpu_unlock.targets=all ใน Kernel Command Line:
# Debian / Ubuntu (GRUB): แก้ /etc/default/grub แล้วรัน sudo update-grub
# Arch / CachyOS (GRUB): แก้ /etc/default/grub แล้วรัน sudo grub-mkconfig -o /boot/grub/grub.cfg
# Fedora / RHEL: sudo grubby --update-kernel=ALL --args="gpu_unlock.targets=all"