استفاده از اشکال ولتاژ برای آزاد کردن A100 در کارت استخراج من

من یک آسیب‌پذیری تزریق خطای ولتاژ را در قالب GA100 کشف کرده‌ام که به اپراتور اجازه می‌دهد فیوزهای دلخواه را منفجر کند. با استفاده از این آسیب‌پذیری، کارت CMP 170HX 8 گیگابایتی خود را به یک A100-80G تبدیل کردم! علاوه بر این، کارت‌های قفل‌شده من در واقع 1.2 برابر سریع‌تر از A100 خرده‌فروشی عمل می‌کنند، زیرا همه SM‌های کاربردی فعال هستند (~120-126، وابسته به قرعه‌کشی)، به جای کارت‌های ایمن 108 SM که NVIDIA برای همه کارت‌های A100 تولیدی انتخاب کرد.

در نهایت، ویژگی‌های غیرفعال‌شده CMP مانند NVLink، PCIe Gen4، NVJPG، NVDEC، MIG همگی با این رویکرد قابل باز شدن هستند، اگرچه من به‌طور خاص NVJPG/NVDEC/MIG را آزمایش نکرده‌ام.

در اینجا نحوه نمایش و عملکرد "A100-80G" من آمده است.

NVIDIA از فیوزها برای بخش‌بندی محصول، ویژگی‌های امنیتی و سایر ویژگی‌های کنترل دسترسی سرگرم‌کننده استفاده می‌کند - و مهمتر از همه، چندین عملکرد وجود دارد که در آن دمیدن فیوز در قالب NVIDIA می‌تواند به شما دسترسی بیشتر و نه کمتر را بدهد. در طراحی ایمن شده مناسب، یک فیوز سوخته همیشه باید حالت محدودتری ایجاد کند، زیرا فیوز سوخته را نمی توان به روشی مقرون به صرفه باز کرد. طراحی انویدیا به فرد اجازه می‌دهد تا با فشردن فیوزهای بیشتر، محدودیت‌ها را کاهش دهد!

در این پست به بررسی قالب GA100، کنترل کننده فیوز آن، استفاده از VFI و دستورالعمل های تحقیقاتی آینده می پردازم. من تصمیم گرفتم برخی از کارهایی را که امکان تحقیق من را فراهم کرد در اینجا منتشر کنم.

کار من بر اساس تحقیقات قبلی جان پری و بسیاری دیگر است که بیشتر وقت خود را صرف درک بهتر قالب GA100 کرده‌اند. من یافته های خود را بعد از اینکه محقق امنیتی دیگری به طور مستقل همان آسیب پذیری را کشف کرد، افشا می کنم. من معتقدم این به نفع عموم است که این اطلاعات در دسترس عموم قرار گیرد. این یافته ها قبل از انتشار این مقاله برای تیم امنیت محصول NVIDIA فاش شد.

GA100 یک قالب NVIDIA است که برای تامین انرژی تقریبا 20 SKU مختلف استفاده شده است - A100 شناخته شده ترین نوع آن است. من به هر SKU نمی‌پردازم، اما جلوه‌های GA100 را که برای کارم مهم هستند، ارائه می‌دهم که نسخه‌های مختلف CMP 170HX و A100 را پوشش می‌دهد.

همانطور که گفته می شود، قالب GA100 دارای 128 SM، 12 FBP، 5 واحد NVDEC، یک کنترلر PCIe Gen4 x16 است و بسته به اندازه فریم بافر، دارای 4 تا 6 پشته HBM همراه با قالب است. NVIDIA از eFuse ها برای کنترل بازده و تقسیم بندی محصول استفاده می کند - GA100 های تمایز نیافته بر اساس آزمایش نقص و تقاضای سازنده به انواع محدودتر تبدیل می شوند.

در یکی از افراطی‌ترین جلوه‌های تقسیم‌بندی محصول، CMP 170HX، یک کارت استخراج اتریوم با ظرفیت اسمی 8 یا 10 گیگابایت فریم‌بافر در معرض برنامه، در واقع به ترتیب دارای 80 و 40 گیگابایت HBM داخلی است! این کار عمدتا بر چگونگی باز کردن کامل قفل و استفاده از آن ظرفیت متمرکز است. کارهای قبلی پیشرفت های زیادی در باز کردن قفل GA100 از طریق روش های نرم افزاری داشته است. VFI ما را در آخرین مایل می برد.

بنابراین، NVIDIA چگونه از فیوزها برای تولید یک مرکز داده A100 و یک کارت CMP استخراج از یک قالب استفاده می کند؟ برای درک این موضوع، باید نگاهی دقیق‌تر به کنترل‌کننده فیوز واقع در GA100 بیندازیم.

کنترل کننده فیوز بلوکی است که شامل 16384 eFuse (512 ردیف 32 تایی) و یک دسته منطق اطراف آن ماکرو فیوز خام است. وظیفه آن انجام بازخوانی و برنامه نویسی فیوز، محافظت از فیوزهای زیرین و ارائه «کلمات گزینه» قابل استفاده به بقیه قالب است. این کلمات گزینه متعاقبا تصمیم می‌گیرند که قالب چگونه عمل کند و چه ویژگی‌هایی فعال شوند.

هر eFuse می تواند در یکی از دو حالت باشد (blown=1، unblown=0) و 512 ردیف به 4 منطقه تقسیم می شوند:

دو گروه بسیار جالب از فیوزها برای باز کردن قفل مبتنی بر VFI وجود دارد:

قبل از اینکه برخی از کلمات گزینه کدگذاری شده با FF را نام ببریم، ابتدا باید فرمت ضبط FF را با جزئیات بیشتری درک کنیم، سپس در مورد بلوک های قالبی که بر ویژگی های مورد علاقه ما حاکم است صحبت کنیم.

هر ردیف FF یک رکورد 32 بیتی است. بیت های 0-4 یک زنجیره را انتخاب می کنند، بیت 5 FF را از IFF متمایز می کند (0 برای FF)، بیت های 6-15 یک بلوک 16 بیتی را انتخاب می کنند، و بیت های 16-31 مقدار جدید آن بلوک را تامین می کنند. تصویر زنجیره JTAG از پتنت در اینجا کاملا تحت اللفظی است: کنترل کننده داده های گزینه را با پخش مجدد این رکوردها در زنجیره ایجاد می کند. مکان های ثابت در هر زنجیره با کلمات گزینه جداگانه مطابقت دارد.

اگر دو رکورد به یک زنجیره و یک بلوک اشاره کنند، رکورد بعدی برنده می شود. به عنوان مثال، 0x0fe805c1 به معنای زنجیره 1، بلوک 23، داده 0x0fe8 است. اضافه کردن آن رکورد می تواند یک بیت موثر تنظیم شده توسط یک رکورد FF قبلی را پاک کند. هیچ فیوز فیزیکی منفجر نشده است. یک ردیف جدید جایگزین بلوک 16 بیتی قدیمی می شود. این برای گزینه های دارای پشتوانه FF کار می کند، نه فیوزهای کنترلی معمولی در ردیف های 0 و 1.

اکنون که می دانیم کلمات FF چگونه رمزگذاری می شوند، در اینجا لیستی از کلمات جالب و مکان آنها آورده شده است. اینها توسط یک محقق مفید کشف شد که مقادیر FF و کلمات گزینه موثر را از SKUهای مختلف GA100 به منظور درک متفاوت نگاشتهای کلمه زنجیره FF / بلوک به گزینه، مقایسه کرد، زیرا نگاشت رسمی شناخته شده ای وجود ندارد.

کلمات اختصاری FBIO/FBPA/FBP/TPC/GPC/PES/ROP همگی به عناصر ریزمعماری اشاره دارند، لطفا این نمودار را از کاغذ سفید GA100 ببینید تا بیشتر متوجه شوید که اینها چگونه به یکدیگر مرتبط هستند:

FBP اصطلاح داخلی NVIDIA برای "پارتیشن بافر فریم" است، با 2 FBP به یک پشته HBM. FBPA ها پارتیشن های فرعی هستند، 2 FBPA به یک FBP. PES/ROP بلوک‌هایی هستند (به ظاهر مرتبط با گرافیک) که برای عملکرد SM مورد نیاز هستند.

با در دست داشتن این دانش، چه می‌شود اگر بتوانیم ردیف‌های FF جدیدی بنویسیم که کلمات _DISABLE را صفر باشند، یا حداقل با توجه به نقص‌های قالب، تا حد امکان مجاز باشند؟ اگر به نحوه استفاده از گزینه های _DISABLE همراه با عناصر دیگر نگاه کنیم، به سرعت متوجه خواهیم شد که این کلمات _DISABLE اهرم اصلی ما برای جلوگیری از «کف‌روبی» قسمت‌هایی از قالب هستند. پس از روشن کردن "چه می‌شود"، من در مورد "چگونه" صحبت خواهم کرد: کاربرد دقیق تزریق خطای ولتاژ و محافظ‌های کنترل کننده فیوز که می‌توانیم با VFI شکست دهیم.

NVIDIA این گزینه‌ها را مسئول تنظیم سیگنال‌های کف‌روبی می‌کند، که باعث می‌شود عنصر دای غیرقابل دسترس (و احتمالا خاموش شود). از آزمایش‌ها، من معتقدم خطوط کف‌شوی در RTL مشخص شده‌اند، که از کنترل‌کننده فیوز سرچشمه می‌گیرند و به بلوک‌های عملکردی منتهی می‌شوند و برخی از سوئیچ‌های اصلی دامنه پاور/ساعت درون بلوک را کنترل می‌کنند. من رفتار کف‌روبی را مشاهده کرده‌ام که با تأخیر بسیار کمی با مقدار کلمات وضعیت مؤثر کنترل‌کننده فیوز برای هر بلوک عملکردی مطابقت دارد.

به عنوان مثال، کف‌شویی FBP را در نظر بگیرید. در یکی از کارت های 8 گیگابایتی من، OPT_FBP_DISABLE 0x852 بود: FBP های 1، 4، 6 و 11 ماسک شده بودند. ماسک جداگانه OPT_FBP_DEFECTIVE 0x840 بود که 6 و 11 را پوشش می داد. پس از اینکه ماسک غیرفعال با پشتیبان FF را با ردیف FF جایگزین به 0x840 کاهش دادم، ماسک های اضافی در 1 و 4 از بین رفتند، اما 6 و 11 معیوب غیرفعال ماندند. این باعث می شود 10 مورد از 12 FBP موجود در ماسک موثر باقی بماند. از نظر عملکردی، FBP های 1 و 4 که وقتی OPT_FBP_DISABLE 0x852 بود از خواندن و نوشتن ثبت خودداری کردند، پس از نوشتن فیوز پاسخگو شدند.

اگرچه بلوک‌های عملکردی را می‌توان با نوشته‌های FF «کاهش زد» کرد، اما این برای ارائه کامل بلوک به یک برنامه نهایی کافی نیست - برای مثال، پیکربندی هندسه فریم‌بافر پیش‌فرض تنها از بخشی از هر پشته HBM موجود استفاده می‌کند.

برای دور زدن آن، می‌توانیم از چیزی که اساسا یک تغییر کوچک در روش cmpunlocker است استفاده کنیم. وصله درایور معمول برای باز کردن قفل های 8 -> 64 گیگابایتی روی مجموعه خاصی از کلمات پیکربندی ویژگی (FBPA_CFG، SM_SPEED_SELECT، و غیره) می نویسد. مقادیر پیش‌فرض برای موفقیت در نوع رایج 170HX انتخاب شده‌اند که دارای کلمات گزینه مشتق شده از _DISABLE FF است که از استفاده از بلوک‌های عملکردی خاص جلوگیری می‌کند (هر تلاشی برای استفاده از آنها خطاهای طبقه‌بندی را برمی‌گرداند).

با باز کردن رایت FF در جای خود، می‌توانیم حتی کلمات مجاز بیشتری را در رجیسترهای پیکربندی بنویسیم، که در نتیجه A100-80G است.

با اطلاعاتی که در اختیار داریم، به نظر واضح می‌رسد که اگر بتوان فیوزهای FF دلخواه را منفجر کرد، هر GA100 می‌تواند به‌طور کامل به حداکثر توانایی خود باز شود، همانطور که با بازده قالب و پشته‌های حافظه پر شده تعیین می‌شود. اما چگونه فیوزهای FF را باد کنیم؟ بیایید برای درک بیشتر به عملکرد برنامه ریزی فیوز کنترل کننده فیوز نگاهی بیندازیم.

برای درخواست سوختن فیوز، باید به رجیسترهای FUSEADDR، FUSEWDATA و FUSECTRL متعلق به کنترل کننده فیوز بنویسید. اگرچه به طور اسمی برای میزبان یا متقاضیان غیرمجاز قابل دسترسی نیست، با Canary در ROP معدن کریپتو، باز کردن ماسک‌های سطح امتیاز مسئول بی‌اهمیت است. و بنابراین، بسیاری از محققان تلاش کرده اند تا کنترل کننده فیوز را مجبور کنند که فیوزها را در منطقه FF منفجر کند. برخی از مشاهدات مشترک ما به شرح زیر است:

کلمه گزینه خاصی که من به آن اشاره می کنم OPT_SECURED_BURN_FEATURE_ENABLE ("SBFE") است و در همه کارت های تولیدی 1 تنظیم شده است. وقتی این کلمه گزینه واضح باشد، برنامه نویسی فیوز در هر آدرسی مجاز است. وقتی تنظیم شود، فقط فیوزهای FPF ممکن است سوخته شوند. تا به امروز، هیچ کس راهی برای سوزاندن فیوزهای FF با SBFE=1 پیدا نکرده است، حتی زمانی که کنترل کننده فیوز را از زمینه های HS کار می کند. مشخص نیست که واقعا «سوزاندن ایمن» به چه معناست، من حدس می‌زنم که باید یک راه نرم‌افزاری برای انجام رایت‌های غیرFPF حتی با SBFE=1 وجود داشته باشد، و ما فقط نمی‌دانیم که صفت «ایمن» واقعا در اینجا به چه معناست.

توجه داشته باشید PLM , HS , ucode , …. با عمیق‌تر شدن توضیحات، من در حال بررسی استفاده از یک سری اصطلاحات خاص NVIDIA در این بخش هستم. برای توضیح واقعا عمیق معنای اینها، من شما را به منابع دیگری مانند Je Ne Sais Quoi - Falcons Over the Horizon ارجاع می دهم.

نکته مهم، همانطور که مردم متوجه شده‌اند کارت‌های مجاز بیشتری دارند، امکان انجام رایت FF با SBFE=0 وجود دارد! و همانطور که مشخص است، دستیابی به این حالت نحوه دستیابی به قفل GA100 است. پس از آزمون و خطای بسیار، به القای این حالت از طریق تزریق خطای ولتاژ متوسل شدم و توانستم به آن برسم. بیایید در مورد نقص ولتاژ بیشتر صحبت کنیم.

در مورد VFI بسیار گفته شده است و من توضیح عمیق را به منابع دیگر واگذار می کنم. به طور خلاصه، اعمال پالس های کوتاه ولتاژ تغذیه پایین اغلب باعث رفتار غیرمنتظره در مدارهای مجتمع می شود. من از GPT-6 Astra خواستم که یک برد مبتنی بر STM32G4 طراحی کند که به سیگنال PWMVID روی PCB CMP ضربه می زند. PWMVID یک استاندارد NVIDIA برای تنظیم کننده های ولتاژ است، و گلیچر من سیگنال PWM منتشر شده توسط قالب GA100 را قطع می کند و آن را با شکل موج خودش که به آی سی درایور MP2888B VRM تغذیه می شود، جایگزین می کند.

با راه‌اندازی‌ام، می‌توانم VRM خود کارت را وادار کنم تا اشکالات زمان‌بندی شده برای من ایجاد کند، که ساده‌تر از تنظیمات مبتنی بر ماسفت است و خطای سریع‌تری را نسبت به تلاش برای هدایت مستقیم PMBus امکان‌پذیر می‌کند.

گلیچر به دو اتصال به PCB نیاز دارد که در حالت ایده آل با سیم آهنربایی/ میناکاری شده انجام می شود. یک سیم برای سنجش ولتاژ به NVVDD ضربه می زند و سیم دیگر به سیگنال PWMVID ضربه می زند. تنها مرحله مورد نیاز دیگر برای عملکرد گلیچر، حذف یک مقاومت 0402 اهمی است که ارتباط بین پین PWM خروجی GA100 و آی سی VRM را قطع می کند. یافتن محل قرار دادن شیرها با ردیابی پین‌آت MP2888B، به‌ویژه پین‌های PWMVID و VOSEN آن بی‌اهمیت است (MP2888B با تراشه عمومی برادر خود MP2888A ردپایی مشترک دارد).

نقاط تست مستقیما در مجاورت MP2888B نصب نسبتا آسان شیر PWMVID را امکان پذیر می کند.

با این ضربه زدن در جای خود، یک تلاش برای خطا شامل این دنباله می شود:

راه‌اندازی من با یک انتقال ساده ACPI S0 -> S3 -> S0 به مراحل 1/2 دست می‌یابد، که می‌تواند در چند ثانیه در یک پلتفرم دسک‌تاپ مدرن انجام شود. تغییرات مزاحم تر یا دکل های گران قیمت احتمالا می توانند به نرخ آزمایش بهتری دست یابند، اما در تجربه من این تنظیم برای باز کردن قفل کارت ها در زمانی بین 1 ساعت تا 48 ساعت با استفاده از روشی که بعدا توضیح داده شد کافی است.

برای آستانه NVVDD، سیستم عامل Astra از یک مقایسه کننده STM32 برای تشخیص زمانی که NVVDD از 225 میلی ولت عبور می کند، استفاده می کند، پس از آن یک حلقه DMA محکم وظایف مورد نظر را روی پین PWMVID هدایت می کند. بعد از S0، میزبان وضعیت کارت را بررسی می کند و تصمیم می گیرد که چه کاری انجام دهد. اگر شامل اشکال دیگری باشد، برد گلیچر از طریق USB با یک الگوی اشکال فرمان داده می شود. سپس میزبان S3 را با یک تایمر RTC القا می کند تا در 3 ثانیه از خواب بیدار شود (دوره به دست آمده تجربی برای ثبات مناسب).

گاهی اوقات هاست در بازگشت به S0 شکست می‌خورد، من این مشکل را با انتقال حسابداری و آماده‌سازی کمپین نقص به SBC (Radxa Cubie A5E) برطرف کرده‌ام که همچنین می‌تواند پین‌های دکمه پاور/ریست مادربرد را از طریق GPIO در صورت عدم پاسخگویی میزبان هدف اشکال، هدایت کند.

در صورت علاقه، جزئیات بیشتر در مخزن GA100VFI به اشتراک گذاشته شده است. در حال حاضر، بیایید نگاهی به حالات مختلف جالبی که می‌توانیم از طریق VFI ایجاد کنیم، و همچنین وضعیت اشکال خاصی که برای رایت ردیف‌های FF نیاز داریم، بیاندازیم. برای کمک به روشن کردن تفاوت‌های بین هر حالت اشکال، من یک مدل تجربی از نحوه راه‌اندازی کنترل‌کننده فیوز هنگام اعمال ولتاژ ایجاد کرده‌ام. توجه داشته باشید که بدون RTL که کنترل کننده فیوز را پیاده سازی می کند، تنها چیزی که داریم حدس و گمان است. در اینجا مراحل فرضی بوت وجود دارد:

این مراحل فرضی بر اساس آن چیزی است که من واقعا می توانم از قالب بخوانم: حالت های کنترل کننده، ردیف های خام زمانی که CMD_READ کار می کند، کلمات گزینه منتشر شده، و اینکه آیا حلقه PRI همچنان می تواند به بقیه GPU برسد یا خیر. با نگاه کردن به چند مقدار کلیدی، می‌توانیم نتایج خطا را از هم تشخیص دهیم. نکته مهم این است که الگوهای اشکال و پیامدها بسیار خاص هستند، بنابراین شکل موج‌ها و پاسخ‌های نمونه را به عنوان مثال در نظر بگیرید. بیایید نگاهی به 3 حالت اشکال جالب بیندازیم.

برخی از اشکالات باعث می شود تقریبا هر کلمه گزینه منتشر شده به عنوان صفر خوانده شود. در یک حالت ضبط شده، 669 مورد از 672 خوانده شده گزینه صفر بود. سه مورد دیگر پاسخ های خطا بودند. وضعیت CRC کنترلر 0x00 بود (هنوز تجزیه نشده است)، شناسه PCIe به عنوان 2080 خوانده می‌شود (شناسه پایه محصول GA100 PCIe، با یک محصول خرده‌فروشی واقعی مطابقت ندارد)، و حلقه PRI GPU در حالت تنظیم مجدد قرار داشت.

این حالت با یک خرابی فاجعه بار از طرف کنترل کننده فیوز سازگار است. کارت اساسا غیرقابل استفاده می شود، زیرا تقریبا تمام عملکردهای بوت توسط حالت صفر مختل می شوند. با این حال، به اندازه کافی جالب است، این کارت به صورت بومی در PCIe Gen4 آموزش می بیند! برخی از انواع کمی تغییر یافته ممکن است بخش هایی از فیوزها را نشان دهند که با موفقیت قفل شده اند یا به جای صفرهای تمام، حاوی مقادیر مخدوش هستند. من نتوانستم هیچ یک از این حالات را به سمت سوختگی FF سوق دهم. تقریبا در همه آنها کنترل کننده فیوز غیرقابل دسترس یا ناکارآمد است.

خواندن داده‌های RIR در CMP 170HX 8GB تأثیر دقیق آن را نشان می‌دهد: 15 دستورالعمل تعمیر نوپ، و یک نوشته که ارزش فیوز ردیف 18 را تغییر می‌دهد که کلمه گزینه آن را می‌توانیم نظارت کنیم. علاوه بر این، از آنجایی که حس RIR به‌جای مستقیما توسط کنترل‌کننده فیوز، به‌صورت داخلی توسط ماکرو فیوز مصرف می‌شود، می‌توانیم با تلاش برای خواندن ردیف خام، یک قفل RIR مختل شده را مشاهده کنیم - بیت‌فلیپ مشاهده‌شده در سراسر کلمه گزینه برگشتی و همچنین ردیف فیوز خام ثابت می‌ماند.

این یک نقطه بازرسی زمانی جالب در بررسی بوت قالب ایجاد می کند (حس RIR باید قبل از سایر سنجش فیوز اتفاق بیفتد)، اما به خودی خود یک نقص مفید نیست.

به نظر می‌رسید که حالت موفقیت آمیز سه پالس در کارت اول من دقیقا کلمات گزینه مبتنی بر ردیف 0/1 را مختل می‌کند، در حالی که سایر فیوزها و کلمات گزینه را دست نخورده باقی می‌گذارد. در این حالت، تمام کلمات گزینه مشتق شده از row0/1 صفر هستند. بازخوانی های اولیه به این صورت است:

در این مرحله، ما هنوز قادر به صدور FF نوشتن نیستیم، زیرا ENABLE_FUSE_PROGRAM=0. من صادقانه مطمئن نیستم که چرا ENABLE_FUSE_PROGRAM با توجه به 1 در تابلوهای خرده فروشی صفر می شود، بنابراین این تقریبا برای من شبیه راهی برای پیاده سازی یک قناری تشخیص اشکال است (یا حداقل انجام این کار زیبا خواهد بود).

سنجش فیوز یک ردیف در یک زمان اتفاق می‌افتد، با تمام 32 فیوز برای سنجش با یک خط، به این معنی که برای مهاجم بسیار چالش‌برانگیزتر است که یک فیوز را پاک یا تنظیم شده نشان دهد. بنابراین منطقی است که فیوز قناری را در نظر بگیریم که ویژگی‌های حیاتی امنیتی (مانند سوختن فیوز) را هنگام پاک کردن غیرفعال می‌کند، زیرا معمولا مهاجم فقط می‌تواند حسگر فیوز را حداکثر در دانه‌بندی ردیف دستکاری کند. بنابراین، هنگامی که کلمات گزینه row0/1 ظاهر می شوند و همه پاک می شوند، ENABLE_FUSE_PROGRAM=0 ما را از سوزاندن فیوزها باز می دارد.

با این حال، به آنچه در این حالت داریم نگاهی بیندازید: DISABLE_SW_OVERRIDE=0. این کلمه معمولا 1 است و ما را از تنظیم رجیستر EN_SW_OVERRIDE بر روی 1 باز می دارد، که سپس به ما امکان می دهد بیشتر کلمات گزینه ای را که توسط کنترل کننده فیوز در معرض دید قرار می گیرند، "سایه" کنیم. انجام این کار شامل نوشتن در یک ثبات CTRL_OPT_*، مربوط به کلمه گزینه OPT_* است، که سپس مقدار موثر STATUS_OPT_* را تعیین می کند. این همان چیزی است که به ما امکان می‌دهد SBFE را 0 سایه کنیم. اما، با وجود اینکه DSOV=0 داریم، ENABLE_FUSE_PROGRAM یکی از گزینه‌هایی است که حتی با DSOV=0 نمی‌توان آن را سایه انداخت. بنابراین به نظر می رسد که ما گیر کرده ایم.

حداقل این چیزی بود که من فکر می کردم و در این حالت برای مدتی سرم را به دیوار کوبیدم. سپس متوجه شدم که یک فرمان کنترل کننده فیوز وجود دارد که من هنوز آن را امتحان نکرده ام: SENSE_CTRL. من از صدور آن خودداری کرده بودم، زیرا ظاهرا به نظر می رسد که همه کلمات گزینه مشتق شده ردیف 0/1 (فیوز کنترلی) با مقادیر ذوب شده خود مطابقت دارند، که SBFE را بازنشانی می کند، سایه زدن کلمه گزینه نرم افزار را خاموش می کند و ما را قادر به فیوز کردن نمی کند.

در کمال تعجب، وقتی این دستور را صادر کردم، همه گزینه های مشتق شده از کنترل فیوز به مقدار فیوز شده خود رفتند، به جز DISABLE_SW_OVERRIDE که 0 باقی ماند!

با DSOV=0، می‌توانیم SBFE را روی 0 تنظیم کنیم، ENABLE_FUSE_PROGRAM 1 است زیرا با مقدار ذوب شده آن مطابقت دارد، و ما به مسابقه می‌رویم! یک چروک در آن باقی می‌ماند که FUSEWDATA ممکن است یک PLM قفل شده داشته باشد، اما با DSOV=0، می‌توانیم فقط 0 را در OPT_SECURE_FUSE_WDATA_WR_SECURE بنویسیم تا PLM را در حالت یکپارچه قرار دهیم و دسترسی میزبان را برای فیوزینگ باز کنیم.

در این مرحله، تنها کاری که باید انجام دهید این است که کلمات _DISABLE را که با مقادیر _DEFECTIVE مطابقت دارند برای ویژگی‌هایی که به آن‌ها علاقه مندیم، محاسبه کرده و FF burns را صادر کنیم. توجه داشته باشید که فضای اشغال شده FF و بیت های معیوب به ازای هر قالب متفاوت است، بنابراین هر سوختگی باید به شکل قالب طراحی شود.

در کارت‌های 8 گیگابایتی با 80 گیگابایت دست نخورده (به نظر می‌رسد حدود 90 درصد از کارت‌های 8 گیگابایتی از اندازه نمونه محدود من است)، باز کردن قفل 80 گیگابایت کامل را به عنوان یک فریم بافر قابل استفاده به دست می‌دهد. چندین آزمایش مصنوعی (نوشتن کلمات شبه تصادفی در سراسر فریم بافر کامل و خواندن آنها پس از باطل شدن L2) و همچنین بارهای کاری واقعی (مانند vLLM و SGLand) کاملا کاربردی هستند. همانطور که گفته شد، یکی از کارت های من فقط 64 گیگابایت دست نخورده دارد. در این مورد، باز کردن قفل سخت افزاری هیچ مزیتی بافر فریم به همراه ندارد.

170HX به 70 اس ام اس خارج از جعبه محدود شده است. در عمل، تقریبا همیشه بیش از 120 اس ام اس غیر معیوب روی قالب وجود دارد و باز کردن قفل اجازه استفاده از همه آنها را می دهد. این منجر به بهبود عملکرد قابل توجهی می شود، ~ 1.7 برابر در مقایسه با باز کردن قفل نرم افزاری 170HX، و حتی ~1.2x قابل توجه نسبت به A100 خرده فروشی!

تنها چیزی که مانع از پیشرفت cmpunlocker فراتر از PCIe Gen2 می شود، کلمات گزینه FF هستند. با پاک شدن بیت‌های مربوطه، Gen3/4 آموزش می‌دهد و کاملا کاربردی بودن تأیید شده است. هنگامی که با حالت خازن جداکننده PCIe ترکیب می شود، تا PCIe Gen4 x16 قابل دستیابی است که با نوع خرده فروشی A100 PCIe مطابقت دارد.

به صفر رساندن کلمه OPT_NVLINK_DISABLE تنها یکی از مدهای مورد نیاز برای کارکرد واقعی NVLink است. از آنجایی که PCB CMP 170HX فاقد آی سی U11 است (که PCIe 3.3v را به پین ​​پل NVLink متصل می کند)، یک برد استوک نمی تواند ژنراتور ساعت مرجع را روی پل های NVLink متصل نشان دهد. به سادگی پل زدن دو پین روی ردپای U11 این مشکل را حل می کند، اگرچه هر گونه مقررات یا حفاظتی که توسط U11 ارائه شده بود را حذف می کند.

مراقب باشید اگر پردازنده‌های گرافیکی را با منابع تغذیه مختلف متصل می‌کنید، زیرا با این کار ریل‌های +3.3 ولت به یکدیگر متصل می‌شوند مگر اینکه U11 را روی برخی از GPU‌های خود خالی بگذارید! اگر U11 را روی یکی از بردهای جفت قرار دهید، پل NVLink به خوبی کار می کند.

در سمت سیستم‌افزار فعال‌سازی NVLink، یک بررسی ROM وجود دارد که باید با دستورات سمت میزبان اضافی دور زده شود. من مطمئن هستم که کلاهک شما می تواند آن را بفهمد ;)