مشاكل وميزات تنفيذ UEFI على منصات مختلفة

لقد مرت حوالي تسعة عشر عامًا منذ إصدار أول مواصفات EFI في عام 2000. لقد استغرقت الواجهة عشر سنوات لدخول سوق المستخدم والحصول على موطئ قدم لها. في الوقت الحالي ، نادرًا ما يمكنك رؤية جهاز كمبيوتر حديث بدون UEFI في البرامج الثابتة للوحة الأم. وزاد معيار الواجهة "اللحوم" وعدة آلاف الصفحات في الوثائق الرسمية. بالنسبة للمستخدم العادي ، لم يتغير شيء ، باستثناء التصادمات العرضية مع تمكين التمهيد الآمن. ولكن إذا تحول مستوى العمل إلى التطوير ، يصبح كل شيء أكثر إثارة للاهتمام.



يشير مفهوم البنية المعيارية لـ UEFI إلى أنه لا يمكن استخدام هذه الوحدات فقط في التكوين القياسي ، ولكن أيضًا تنزيل شيء خاص بها. برنامج تشغيل نظام الملفات (على سبيل المثال لا الحصر efi-shy FAT؟) ، برامج تشغيل الأجهزة الطرفية ، التطبيقات ، برامج تحميل التمهيد - يمكنك تحميل كل شيء يدويًا ، سيكون من الرائع تحميل القليل من Shell. يمكنك اتخاذ خطوة "أعمق" وإلقاء نظرة على محتويات البرنامج الثابت ، مما ينقذ نفسك من الرقص مع SecureBoot والحاجة إلى كتابة طبقة من البرامج النصية (هناك مقالات كافية على صفحات المحور).

على هذا الأساس ، ولدت فكرة إنشاء وحدات وظيفية تؤدي وظائف أمان مختلفة قبل تحميل نظام التشغيل ، والتي يمكن أن تتحد وتصبح نوعًا من بيئة التمهيد الموثوقة المتكاملة التي تؤثر على كل من خدمات واجهة التشغيل ووقت التشغيل بحيث يكون بين الوحدات في البرامج الثابتة والوحدات الموجودة على القرص لا يمكن "دفع" أي شيء دون تدخل على مستوى منخفض ، وبعدهم - فقط بإذن من مسؤول الأمان.

قدم لنا تنفيذ هذه الفكرة عددًا كبيرًا من الفروق الدقيقة والفروق الدقيقة في UEFI - بدءًا بالعديد من الميزات والأخطاء غير الموثقة أو غير الموثقة بشكل جيد ، وانتهاءً بالسلوك غير المحدد الذي يحبه جميع المطورين. لنبدأ بالترتيب.

الاعتماد على المنصة




أول شيء تحتاج إلى معرفته عند الاندماج في النظام الأساسي هو ما إذا كان يمكننا العمل معه؟ يعتبر إصدار مواصفات UEFI مهمًا ، وفي معظم الأجهزة يتم تقديمه في النطاق بين 2.1 و 2.7. الأحدث لم يصل بعد إلى منصة البحث. تم العثور على القديم ، وقد يكون أدائه محدودًا بسبب عدم وجود البروتوكولات اللازمة أو برامج التشغيل المكتوبة بشكل معوج لتنفيذها. على سبيل المثال ، غالبًا ما تكون UnicodeCollation غير كافية ، عند الوصول إلى smbios هناك أخطاء غير موثقة ، لا تعمل وظائف تغيير اللغة من خلال SetVariable (). يمكن أن يحدث أي شيء ، اعتمادًا على البائع والنضارة ، لأنه في بعض الأحيان يجب عليك وضع البروتوكولات الخاصة بك حتى على لوحات جديدة نسبيًا.

حتى في ممارستنا ، كنت محظوظًا بما يكفي لتعثر على جهازي كمبيوتر صغيرين مع Intel Bay Trail D والبرامج الثابتة 32 بت على متنها. الحالة نادرة ، ولكن في وقت واحد جعل من الضروري إعادة تجميع الوحدات بشكل عاجل. في الواقع ، مثل السؤال: هل سنلتقي بمنصة أكثر حداثة بنفس السعة في المستقبل؟ وإذا التقينا ، فأين؟

الخطوة التالية هي تحديد كيفية الدمج. تم تضمين الوحدات النمطية في البرنامج الثابت ، ويقع البرنامج الثابت في شريحة SPI على اللوحة ، ويقع PCH مع Intel ME في مكان قريب. وهنا ينشأ السؤال الأكثر إثارة للاهتمام - كيف تصل إلى هناك؟ مبرمج قديم جيد مع "تمساح" - هذا جيد ، يمكن الاعتماد عليه. حتى إذا لم تتمكن من اللحاق حتى النهاية ، يمكنك دائمًا إلقاء نظرة على مصابيح LED المحترقة على اللوحة ، فهي تتمتع بقوة كافية من المبرمج. إنه يعمل بشكل لا تشوبه شائبة تقريبًا ، باستثناء بعض طرازات HP القديمة ، حيث يمكن الوصول إلى mikruha SOIC-16 مع البرامج الثابتة بحيث يكون من السهل تمييز المحول ولحامه في ساقيها بدلاً من الضغط على المقطع.



أعلم أن هناك أشخاصًا في حبري ساهموا في كتابة الفلاش ، شكرًا لهم بشكل منفصل.

ولكن ، على الرغم من موثوقية وموثوقية إزالة التفريغ من قبل المبرمج ، فإن هذه الطريقة ليست مناسبة إذا كنت بحاجة إلى تثبيت شيء ما في UEFI على العديد من الأجهزة ، أو إذا لم يكن النظام الأساسي للتثبيت على مكتبك. لحسن الحظ بالنسبة لنا ، فقد ترك المصنعون أدوات مساعدة البرامج الثابتة الأصلية: FPT (أداة برمجة الفلاش) من مجموعة أدوات نظام Intel (CS) ME ، و AFU (تحديث البرامج الثابتة AMI) لـ Aptio من American Megatrends. يتم تشغيل هذه الأدوات المساعدة من بيئة EFI ومن أنظمة تشغيل Windows و Linux و DOS. الأدوات قابلة للتبادل إلى حد ما ، كلاهما يسمح لك بالنظر في الصورة ، إن لم يكن كلها ، ثم مناطق معينة بالتأكيد. وأحيانًا يسمحون لك بالكتابة.



يكتب ولا يكتب

هذا هو المكان الذي تظهر فيه أول عثرة خطيرة على طريق التكامل. لا تسمح لك جميع اللوحات الأم بقراءة البرنامج الثابت بالكامل ، مما يحظر الوصول إلى منطقة الشرق الأوسط (تكاد تكون ME مقدسة ، ولن تسمح Intel بقراءتها بطريقة جيدة ، ولكن بطريقة سيئة لا نريدها دائمًا). حتى أقل - صب شيئًا حتى في منطقة BIOS ، ما لم تكن كبسولة موقعة. يختلف احتمال النجاح بشكل كبير اعتمادًا على الشركة المصنعة ونضارة الشرائح. في بعض موديلات اللوحات الأم ، يمكنك ملاحظة صورة مضحكة: تلك التي لم يتم تسجيلها على لوحات البائعين القديمة ، تطير في أوقات جديدة.

في بعض الأحيان يساعد محلل IFR على محاربة الحماية ضد الكتابة، الذي يفتح الستارة على الإعدادات والمتغيرات المخفية. وأحيانًا ما يساعد فقط الطائر القوي ، مما يسمح بالوصول إلى التسجيل أو "إيقاف" ME (إذا تم توفير واحد ، بالطبع).

الطبيعة المعقدة للأنظمة


تتم كتابة لوحات Acer و Asus و AsRock و Gigabyte في معظم الحالات دون صعوبات غير ضرورية. أجهزة Intel و HP وأجهزة الخادم متميزة. لا تسمح HP بالكتابة برمجيًا فقط ، ولكنها تقسم أيضًا على أي محاولة لتعديل البرنامج الثابت (فيكودراش هناك مقالات حول إيجاد وتعطيل التحقق من السلامة). سجلت Intel بشكل أو بآخر مجموعة الشرائح 87 ، ثم أصبحت صماء لطلبات فتح بوابات منطقة BIOS.

مع إنتل ، كانت المرة الأولى مضحكة. تم استيراد الوحدات إلى البرامج الثابتة باستخدام أداة UEFITool ، وقد صادفنا خطأ مثيرًا للاهتمام: إذا قمت بإدراج وحدات ffs في نهاية حجم DXE ، بعد كل الأشكال الحرة ، فإن الصورة المجمعة "لبست" اللوحة. كان الحل هو إضافة وحدات نمطية بعد أي برنامج تشغيل DXE أصلي. لم نصل إلى هذا على الفور ، وبدا في البداية أن Intel كانت تراقب سلامة البرامج الثابتة ، مثل HP. في وقت لاحق أصبح من الواضح أنه لا يمكن للمرء الاستغناء عن أداة تلقائية لاستيراد الوحدات النمطية ، ولم تظهر المشكلة بعد كتابتها.

الأجهزة من جانب الخادم أبسط وأكثر تعقيدًا في نفس الوقت. من ناحية ، هناك دائمًا طرق إضافية لتحديث وتعديل BIOSes على الخوادم ، من ناحية أخرى ، فإن حجم التخصيص في نفس BIOSes ساحق ، نظرًا لأنها لا تبخل على الخوادم وتثبت شرائح ذاكرة فلاش كبيرة جدًا ، غالبًا ما تدعمها أيضًا.

عند التثبيت على خادم ، من الجيد دائمًا أن تكون قادرًا على تحديث BIOS عن بُعد عبر IPMI. صحيح ، لهذا بطريقة جيدة تحتاج إلى ترخيص ، بالطبع تدفع. إذا لم تظهر في الوقت المناسب ، فمن الممكن تمامًا الدخول في موقف مضحك مشابه للموقف الذي حصلنا عليه من خلال إدخال وحدات في BIOS خادم سوبرمايكرو.

بعد إدخال الوحدات ، يتجمد الحمل بشدة بسبب الحظر من قبل إحدى وحدات الأمان (لم يأخذوا في الحسبان إزعاج BIOS الخاص بالخادم ، والذي لا يحدث معه!). في غياب القدرة على إجبار BIOS على التراجع عن طريق IPMI ، وصلت اليد نفسها للمبرمج ، لكنها كانت سيئة الحظ - لم يكن مقطع SOIC-8 القياسي كافيًا لشريحة SOIC-16! حسنًا ، حسنًا ، نظرًا لأن لوحة الخادم لديها نظريًا القدرة على النسخ الاحتياطي من الوسائط المتصلة ، والتقاط صورة SUPER.ROM في الجذر. لكن هذه الآلية لا تبدأ ، لأنه وفقًا للنظام ، كل شيء على ما يرام ، كل شيء يعمل ، لذلك ، لا توجد حاجة إلى التراجع عن BIOS! ماذا أفعل ؟! .. انتهى الأمر بالركض في أرجاء المدينة بحثًا عن المقطع الصحيح ، إعادة لحام طارئة للأسلاك ، لطخت من قبل الصينيين في أمر غير مفهوم بالنسبة لنا ، وأخيرًا - وميض.

خرجت لينوفو أكثر إثارة للاهتمام. في المفاتيح المستلمة من البائع ، تحت غطاء العلبة ، تم العثور على لوحة تحكم مع اثنين من "mikruhs" للبرامج الثابتة ، مع SSD لأنظمة التشغيل وبطارية ثابتة. اتضح أن نظام الإدخال والإخراج الأساسي (BIOS) هو أمر صعب ، لم أكن أرغب في تناول صورة معدلة بأي شكل من الأشكال ، واستسلم للمبرمج فقط. في إحدى محاولات كتابة شيء ما ، قاموا بإدخال محرك أقراص محمول مع وحدة تحكم أوبونتو في المحول (لم تعط المحطة الطرفية رسومات) وتمهيدها بأمان تام. بعد القيام بما هو مطلوب ، قاموا بإيقاف تشغيل النظام باستخدام الأمر halt -p من الذاكرة القديمة. لم يكن المفتاح ، بطبيعته ، لا يتكيف مع أي إغلاق ، باستثناء نقص الطاقة ، لم يكن جاهزًا لهذا ولم يرغب في البدء بعد الآن. تم حرق الرابط على الوجه مرة واحدة ، وسرقت المراوح بهدوء ، ولم تقدم كل الموانئ أي شيء. لم يساعد إعادة الوميض ،جلس البطارية مثل القفاز - كنا نخشى كسر الحامل. ونتيجة لذلك ، زحفت لوحة عازلة رقيقة تحت قوة المثابرة والإلهام اللفظي تحت جهات الاتصال ، وتم مسح الذاكرة المتقلبة ، وظهر التبديل إلى الحياة.

أظهرت دراسة المقالب المأخوذة من شظيتين الكثير من الأشياء المثيرة للاهتمام. على وجه الخصوص ، عدد كبير من الإدخالات "غير صالحة" في NVRAM للبرنامج الثابت الرئيسي والعديد من الإدخالات المماثلة في النسخ الاحتياطي. حسنًا ، وليس تجزئة البيانات التي تمت مواجهتها سابقًا في وحدة التخزين باستخدام برامج تشغيل DXE. يمكن للمرء أن يخمن فقط حول السبب الدقيق لمشكلة بدء التبديل.

بشكل عام ، نادرًا ما يُحرم جزء البرنامج من الفروق الدقيقة غير المتوقعة. تحتوي العديد من اللوحات الأم التي جاءت إلينا قبل الشريحة 87 (من شركات تصنيع مختلفة) على ميزة غير سارة لإنتاج دفق لا نهائي من الأخطاء عند إدخال الأمر "dh -v" في وحدة التحكم shell. مع الإدخال اليدوي ، هذا ليس بالغ الأهمية ، ولكن عند جمع البيانات في ملف ، ينتهي الأمر في تعليق مؤسف. في كلتا الحالتين ، يجب عليك إعادة تشغيل الجهاز. أنا سعيد لأنه في نفس الوقت لا يتضخم ملف البيانات إلى أحجام هائلة.



أثبتت Kraftway BIOS مع لوحة ASRock H81M-DGS أنها بعيدة جدًا. لذا ، فإنه يستجيب ل Ctrl Alt Del Del من خلال التعليق ، حيث يمكن فقط إعادة تعيينه. كانت هناك مشاكل في تخطي البرنامج النصي لبدء التشغيل <startup.nsh> في Shell'e - وهي جزء من الثانية للاختيار من بينها بدلاً من خمسة افتراضية. ربما تكون هذه المشاكل ناتجة عن تعديل وحدات KSS الخاصة ، ربما تكون المسألة "غير مفككة" ME بشكل غير دقيق.

على لوحة Asus H97-PLUS ، تحتوي البرامج الثابتة على الميزة التالية - يتجاوز BootOrder بمرور الوقت. على الأرجح ، يكمن السبب في الأخطاء في التعليمات البرمجية. على الرغم من أن الشركة المصنعة ربما أرادت الاحتفاظ بجميع أجهزة التمهيد التي تم توصيلها على الإطلاق في اللوحة ، لكنها لم تحسب أنه يمكن أن يكون هناك أكثر من اثني عشر في يوم واحد. لذلك ، عندما يفيض BootOrder ، يتوقف النظام أثناء عملية التمهيد. لتنظيفه ، يجب إيقاف تشغيل جميع أجهزة التمهيد وتشغيل النظام. يزيل البرنامج الثابت نفسه ويقوم النظام بالتمهيد مباشرة في shell BIOS Setup. يبقى الأداء حتى الفائض التالي.

تلخيصًا لخبرة العمل مع مجالس إدارة العديد من البائعين ، تصل إلى استنتاج أنه يكاد يكون من المستحيل معرفة المفاجآت على مستوى EFI التي ستتعامل معها في اللوحة التالية ، حتى إذا كان لديها بالفعل نموذج معروف. هذا نوع من اليانصيب ، لأنه في بعض الأحيان قد تنشأ صعوبات في مرحلة جمع المعلومات حول النظام. ربما يكون لهذا نصيبًا من المثالية البحثية التي لا تُقهر والإيمان بالمصنع ، لأنه كيف يمكن لبعض اللوحات الحديثة مع ME v11 و v12 أن تتوقف عند تشغيل FPT أو MEInfo للإصدارات الأقدم عليها؟

مشاكل العمل مع بروتوكولات الأجهزة




تظهر بعض المشكلات عندما نبدأ العمل مع أجهزة USB - محركات الأقراص والرموز المميزة. يحدث هذا غالبًا لأن رمز BIOS للعمل مع الأجهزة الطرفية هو مزيج خطير من برامج التشغيل والتطبيقات من بائع الأجهزة المستقل (IHV) لجهاز طرفي معين ، رمز من الشركة المصنعة للشرائح (في حالتنا ، من Intel) ، رمز من الشركة المصنعة لـ BIOS والرمز من الشركة المصنعة للوحة الأم. نشأت

المواقف "المثيرة للاهتمام" التالية:

الرمز "لم يتم اكتشافه". في نفس الوقت ، يضيء مؤشر LED عليه. على الأرجح ، لا تمر وحدة التحكم المضيفة بإجراء إعادة الضبط الأولي لجهاز USB ، أي أن الطاقة يتم توفيرها ، ولكن إعادة التعيين من خلال تغيير خطوط D + و D- لا تعمل بشكل صحيح ، وبدون ذلك ، فإن أي معالجات أخرى مع الرمز المميز لا معنى لها.

يتجمد الكمبيوتر قبل تحميل القشرة (مرة أخرى ، مع توصيل رمز مميز). في هذه الحالة ، بدون رمز مميز ، يبدأ الكمبيوتر بشكل طبيعي. على الهواء ، يبدو الأمر كما يلي: يبدو أن الكمبيوتر يتعطل بعد البداية مباشرة ، بينما يبرز الرمز المميز في الموصل. أخرجها - يستمر التحميل فجأة. ربط - شنقا مرة أخرى. تكمن المشكلة الواضحة في UEFI ، ولا يمكن للمرء إلا التكهن بالأسباب.

الوضع عندما يتعذر فتح واجهة USB_IO. ربما يتم توصيله فقط بواجهة العمل مع البطاقات الذكية - USB CCID. قام برنامج تشغيل AMI بالفعل بفتح USB_IO مع المعلمة EFI_OPEN_PROTOCOL_BY_DRIVER. برنامج التشغيل لديه بروتوكول مع GUID:

#define EFI_AMI_USB_CCID_PROTOCOL_GUID	 { 0x5FDEE00D, 0xDA40, 0x405A, { 0xB9, 0x2E, 0xCF, 0x4A, 0x80, 0xEA, 0x8F, 0x76} }
 // Workaround.      EFI_OPEN_PROTOCOL_BY_DRIVER,  ,     EFI_OPEN_PROTOCOL_GET_PROTOCOL.
 //
 // Open USB I/O Protocol
 //
 Status = gBS->OpenProtocol (
 ControllerHandle,
 &gEfiUsbIoProtocolGuid,
 (VOID **) &UsbIo,
 This->DriverBindingHandle,
 ControllerHandle,
 EFI_OPEN_PROTOCOL_BY_DRIVER
 );

 if (EFI_ACCESS_DENIED == Status)
 {		// AMI BIOS workaround (BindingStop will not be invoked)
	 Status = gBS->OpenProtocol(
		 ControllerHandle,
		 &gEfiUsbIoProtocolGuid,
		 (VOID **)&UsbIo,
		 This->DriverBindingHandle,
		 ControllerHandle,
		 EFI_OPEN_PROTOCOL_GET_PROTOCOL
	 );
 }

ومع ذلك ، لن يتم استدعاء BindingStop () ، أي لا تتم مراقبة حدث استخراج الجهاز ، وسيحاول برنامج التشغيل استخدام مقبض غير صالح. وقد لوحظ ذلك مع جهاز كمبيوتر HP Compaq Elite 8300 SFF وبعض الأجهزة الأخرى. هذا إما نوع من حماية البائع من السائقين غير المرغوب فيهم ، أو خطأ تطوير منتظم. ربما تقوم AMI باستمرار بشيء في اتجاه USB CCID ، ولكن لا يمكن إلغاء تحميل برنامج التشغيل المتداخل ، حيث إنه يقع في نفس وحدة AMI UHCI جنبًا إلى جنب مع USB HID و USB MassStorage. مع UninstallInterface () ، الأمور متشابهة.

أو ميزة أخرى مثيرة للاهتمام. في أحد أنظمة UEFI BIOS ، حيث لم يتم اكتشاف الرمز المميز ، سمح USB_IO بقراءة واصفات الجهاز ، لكن EFI_INVALID_PARAMETER عاد إلى UsbBulkTransfer () التالي. علاوة على ذلك ، حدث هذا فقط مع بعض أنواع الرموز ، مع نفس المعلمات تمامًا ، وبعضها الآخر عمل بشكل مثالي.

بشكل عام ، يتم تطبيق البروتوكول UsbBulkTransfer () بشكل مثير للاهتمام في بروتوكول EFI_USB_IO_PROTOCOL. الغرض منه هو تسليم حزمة مضمونة لفترة غير محدودة ، أو للوقت المحدد في معلمة المهلة. ولكن تم إجراء تجربة باستخدام جهاز MassStorage: عند نسخ ملف كبير إلى محرك أقراص USB محمول ، تمت إزالته. تعليق جهاز الكمبيوتر بإحكام. عند توصيل محرك أقراص USB المحمول ، تراجع الكمبيوتر واستمر في كتابة الملف كما لو لم يحدث شيء. كان نفس الموقف مع الرموز ، ولكن مع تفاصيلها الخاصة. هذه مشكلة معمارية ، في EFI لا توجد مقاطعات باستثناء المؤقت ، والأجهزة تعمل وفقًا لاستطلاع. أي أن النظام قد تعطل في مكان ما في استطلاع USB ، لكنه لم يصل إلى المهلة ، عندما ظهر الجهاز مرة أخرى ، استمر ببساطة وأكمل العملية.

المحاكاة الافتراضية


يجب أن نقول أيضًا عن البيئات الافتراضية. يوجد حاليًا نظامان أساسيان في السوق يدعمان محاكاة بيئة EFI: VMware و VirtualBox. لكل منهما مزاياه وعيوبه عند التفاعل معه كما هو الحال مع الأنظمة "الحقيقية". توفر بيئة VMware بشكل ملائم العمل مع متغيرات NVRAM ، ولكنها تتعثر عند عرض الرسائل بشكل مرئي أثناء تهيئة وحدات DXE: في أفضل الأحوال ، سيتم إعطاء الأفضلية للرسائل الأصلية حول العثور على الوسائط القابلة للتمهيد ، تاركًا ما نحتاجه. على العكس من ذلك ، فإن VirtualBox يقدم كل شيء مطلوب تمامًا ، لكنه لا يريد تذكر المتغيرات الطويلة.

حجر صغير آخر في حديقة VMware - برنامج التشغيل FAT32 المدمج فيه يدعم إنشاء وتحرير الملفات في تدوين 8.3 فقط. ليس من الواضح سبب القيام بذلك ، ولكن هذا قيد يتطلب بوضوح الانتباه. من المحتمل أنه يمكن ملاحظة تنفيذ مماثل للسائق على منصات حقيقية ، ولكن حتى الآن لم نواجهها.

من ناحية أخرى ، في الأجهزة الافتراضية لا توجد رقصات مع أدوات البرامج الثابتة ، والمبرمجين ، والاعبا ، ورقائق غير مريحة. ملف ROM منفصل ، UEFITool وخط في ملف التكوين. تقريبا خرافية.

فى النهاية



شريحة الطلب من CHIPSEC. أين يعلمون مثل هذه الأسرار؟

كما ذكرنا سابقًا ، فإن التطوير والتنفيذ في غلاف UEFI هو عملية رائعة وإبداعية. يمكنك دائمًا العثور على شيء جديد حتى في مجال مشهور. من ناحية ، من المشجع أن المعيار يتطور ، من ناحية أخرى ، من المحزن أن التنفيذ الملموس له من قبل المنتجين "مبدع" للغاية.

كانت المشاكل الرئيسية ولا تزال:

  1. خروج البائعين من مواصفات UEFI عند تطوير البرامج الثابتة.
  2. أخطاء في الكود أثناء التنفيذ.
  3. NDV في التعليمات البرمجية ، المنبثقة أثناء التكامل.

وأخيرًا وليس آخرًا ، غياب العديد من الأشياء في الوثائق الرسمية (قراءة ، مفتوحة) ، على سبيل المثال ، أوصاف البروتوكول للتواصل مع ME عبر أجهزة PCI مثل MEI ، HECI. يمكنك العثور على وصف للسجلات ، ولكن ليس الأوامر. ابحث عن GUID ولكن ليس الغرض منه. وهو ما يعيد العمل مرة أخرى إلى تحليل طويل ، يجمع البيانات والإحصاءات على المنصات ويستخدم أداة التفكيك.

وتجدر الإشارة إلى أن الوضع يصحح ببطء ولكن بثبات ، وأود أن أعتقد أن اللحظة ليست بعيدة عندما يصبح تطوير المعيار عملية يمكن التنبؤ بها إلى حد ما وممتعة للغاية.

فلاديمير Onipchuk ،
رئيس مجموعة منتجات حماية الأجهزة والبرامج من
شركة Gazinformservice LLC

All Articles