دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". المحاضرة 7: رمل العميل الأصلي ، الجزء 3

معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة

أمان أنظمة الكمبيوتر هي دورة حول تطوير وتنفيذ أنظمة الكمبيوتر الآمنة. تغطي المحاضرات نماذج التهديد ، والهجمات التي تهدد الأمن ، وتقنيات الأمان بناءً على العمل العلمي الحديث. تشمل الموضوعات أمان نظام التشغيل (OS) ، والميزات ، وإدارة تدفق المعلومات ، وأمان اللغة ، وبروتوكولات الشبكة ، وأمان الأجهزة ، وأمان تطبيقات الويب.

المحاضرة 1: "مقدمة: نماذج التهديد" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 2: "السيطرة على هجمات القراصنة" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 3: "تجاوزات العازلة: المآثر والحماية" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 4: "فصل الامتيازات" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 5: "من أين تأتي أنظمة الأمن؟" الجزء 1 / الجزء 2
المحاضرة 6: "الفرص" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 7: "وضع حماية العميل الأصلي" الجزء 1 / الجزء 2 / الجزء 3

هناك تحذير واحد في القاعدة ج 4 . لا يمكنك "القفز" في نهاية البرنامج. آخر شيء يمكنك القفز إليه هو التعليمات الأخيرة. لذا تضمن هذه القاعدة أنه عندما يتم تنفيذ البرنامج في عملية "المحرك" ، فلن يكون هناك أي تعارض.

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

تنص القاعدة C6 على أنه يمكن فك جميع التعليمات المتاحة منذ البداية. وبالتالي ، هذا يضمن أننا نرى كل تعليمات ويمكن التحقق من جميع التعليمات التي تعمل عند تشغيل البرنامج.

تنص القاعدة C7 على أن جميع القفزات المباشرة صحيحة. على سبيل المثال ، تقفز مباشرة إلى ذلك الجزء من التعليمات حيث يُشار إلى الهدف ، وعلى الرغم من أنه ليس من مضاعفات 32 ، فإنه لا يزال هو التعليمات الصحيحة التي يتم تطبيق التفكيك عليها من اليسار إلى اليمين.



الجمهور: ما الفرق بين C5 و C3 ؟

البروفيسور: أعتقد أن C5 تقول أنه إذا كان لدي تعليمات متعددة البايت ، فلا يمكنها عبور حدود العناوين المجاورة. افترض أن لدي دفقًا من التعليمات ، وهناك عنوان 32 وعنوان 64. لذا ، لا يمكن للإرشادات عبور الحدود مضاعفة 32 بايت ، أي يجب ألا تبدأ بعنوان أقل من 64 وتنتهي بعنوان أكبر من 64.



هذا ما تقوله القاعدة C5 . لأنه بخلاف ذلك ، بعد أن قفزت من تعدد 32 ، يمكنك الدخول في منتصف تعليمات أخرى ، حيث لا يُعرف ما يحدث.

والقاعدة C3 هي تناظرية لهذا الحظر على جانب القفزة. وينص على أنه كلما تقفز ، يجب أن يكون طول قفزة مضاعفات 32.

يدعي C5 أيضًا أن أي شيء في نطاق العنوان مضاعف لـ 32 هو أمر آمن.

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

افترض أن مدقق وضع الحماية قد حصل بشكل غير صحيح على طول نوع من الإرشادات. ما السوء الذي يمكن أن يحدث في هذه الحالة؟ كيف ستستخدم هذه القسيمة؟

الجمهور: على سبيل المثال ، يمكنك إخفاء استدعاء النظام أو إعادة بيان الإرجاع.

الأستاذ: نعم. لنفترض أن هناك نسخة خيالية من عبارة AND التي كتبتها. من المحتمل أن المدقق قد أخطأ واعتبر أن طوله 6 بايت وطوله الفعلي 5 بايت.



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

وبالتالي ، يجب أن يقوم مدقق Native Client بمزامنة إجراءاته مع إجراءات وحدة المعالجة المركزية ، أي "تخمين" بالضبط كيفية تفسير المعالج لكل تعليمة. وهذا يجب أن يكون على كل مستوى من وضع الحماية ، وهو أمر صعب التنفيذ.

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

إذن أين نحن الآن؟ في الوقت الحالي ، نتفهم كيفية تفكيك جميع التعليمات وكيفية منع تنفيذ التعليمات المحظورة. الآن دعونا نرى كيف نقوم بتخزين الذاكرة والروابط لكل من التعليمات البرمجية والبيانات داخل وحدة Native Client .

لأسباب تتعلق بالأداء ، بدأ عملاء Native Client في استخدام دعم الأجهزة للتأكد من أن تخزين الذاكرة والروابط لا يسبب في الواقع الكثير من الحمل. ولكن قبل التفكير في دعم الأجهزة التي يستخدمونها ، أريد سماع اقتراحات ، كيف يمكنني أن أفعل الشيء نفسه بدون دعم الأجهزة؟ هل يمكننا فقط توفير الوصول إلى جميع عمليات الذاكرة داخل الحدود التي وضعها الجهاز في وقت سابق؟

الجمهور: يمكنك إعداد تعليمات لمسح كل البتات العالية.



الأستاذ: نعم ، هذا صحيح. في الواقع ، نرى أن لدينا هذا والتعليمات هنا ، وفي كل مرة ، على سبيل المثال ، نقفز في مكان ما ، فإنه يزيل الأجزاء المنخفضة. ولكن إذا أردنا الاحتفاظ بكل التعليمات البرمجية الممكنة التي يتم تشغيلها ضمن 256 ميجابايت منخفضة ، فيمكننا ببساطة استبدال السمة الأولى f بـ 0 والحصول على $ 0x0fffffe0 بدلاً من $ 0xffffffe0 . يؤدي هذا إلى مسح البتات المنخفضة وتعيين حد أعلى من 256 ميغا بايت.

وبالتالي ، فإن هذا يفعل بالضبط ما تقدمه ، مع التأكد من أنه عندما تقفز ، فأنت في حدود 256 ميجابايت. كما أن حقيقة قيامنا بالتفكيك يجعل من الممكن التحقق من أن جميع القفزات المباشرة في متناول اليد.

السبب وراء عدم قيامهم بذلك من أجل التعليمات البرمجية الخاصة بهم هو أنه على منصة x86 يمكنك ترميز وفعالية للغاية ، حيث تكون جميع البتات العلوية هي 1. يتحول هذا إلى وجود تعليمات 3 بايت لـ AND وإرشادات 2 بايت للقفز. وبالتالي ، لدينا حساب إضافي 3 بايت. ولكن إذا كنت بحاجة إلى وحدة بت عالية غير وحدة ، مثل هذا 0 بدلاً من f ، فستكون لديك فجأة تعليمات 5 بايت. لذلك ، أعتقد أنهم في هذه الحالة قلقون بشأن النفقات العامة.

الحضور: هل هناك مشكلة في وجود بعض التعليمات التي تزيد من النسخة التي تحاول الحصول عليها؟ أي يمكنك القول أن تعليماتك قد يكون لها تحيز ثابت أو شيء من هذا القبيل؟

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

الجمهور: من الضروري الوصول إلى الذاكرة أكثر من ...

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

على النظام الأساسي x86 ، أو على الأقل على النظام الأساسي 32 بت الموضح في المقالة ، يستخدمون دعم الأجهزة بدلاً من تقييد التعليمات البرمجية وبيانات العنوان التي تشير إلى الوحدات غير الموثوق بها.

دعونا نرى كيف يبدو قبل معرفة كيفية استخدام وحدة NaCl في وضع الحماية. هذا الجهاز يسمى تجزئة. نشأت حتى قبل أن تحصل منصة x86 على ملف مبادلة. على منصة x86 ، يوجد جدول أجهزة مدعوم أثناء العملية. نسميها جدول واصفات المقطع. هي مجموعة من القطع المرقمة من 0 إلى نهاية جدول بأي حجم. هذا شيء يشبه واصف الملفات في Unix ، باستثناء أن كل إدخال يتكون من قيمتين: القاعدة الأساسية وطول الطول.

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



يساعدنا هذا في الحفاظ على حدود الذاكرة على النظام الأساسي x86 ، لأن كل تعليمة ، الوصول إلى الذاكرة ، تشير إلى جزء محدد في هذا الجدول.

على سبيل المثال ، عندما نقوم بتنفيذ mov (٪ eax) ، (٪ ebx) ، أي أننا ننقل قيمة الذاكرة من مؤشر مخزّن في سجل EAX إلى مؤشر آخر مخزن في سجل EBX ، يعرف البرنامج ما هي عناوين البداية والنهاية وبالنظر إلى ، وسيحفظ القيمة في العنوان الثاني.

ولكن في الواقع ، على منصة x86 ، عندما نتحدث عن الذاكرة ، هناك شيء ضمني يسمى واصف المقطع ، مشابه لموصف الملف في Unix . هذا مجرد فهرس في جدول الواصف ، وما لم يذكر خلاف ذلك ، فإن كل رمز عملية يحتوي على قطعة افتراضية.

لذلك ، عند تنفيذ mov (٪ eax) ، فإنه يشير إلى ٪ ds ، أو إلى تسجيل مقطع البيانات ، وهو سجل خاص في المعالج. إذا كنت أتذكر بشكل صحيح ، فهو عدد صحيح من 16 بت يشير إلى جدول الواصف هذا.

وينطبق الشيء نفسه على (٪ ebx) - فهو يشير إلى نفس محدد المقطع ٪ ds . في الواقع ، في x86 لدينا مجموعة من 6 محددات كود: CS و DS و ES و FS و GS و SS . يتم استخدام محدد مكالمات CS ضمنياً لتلقي الإرشادات. لذلك إذا كان مؤشر التعليمات الخاص بك يشير إلى شيء ما ، فإنه يشير إلى ذلك الذي حدد محدد شريحة CS .



تستخدم معظم مراجع البيانات بشكل ضمني DS أو ES ، وتشير FS و GS إلى بعض الأشياء الخاصة ، وتستخدم SS دائمًا لعمليات التكديس. وإذا كنت تدفع & pop ، فإنها تأتي ضمنيا من محدد المقطع. هذه ميكانيكا قديمة نوعًا ما ، ولكن تبين أنها مفيدة للغاية في هذه الحالة بالذات.

إذا تمكنت من الوصول إلى بعض العناوين ، على سبيل المثال ، في المحدد ٪ ds: addr ، فإن الجهاز سيعيد توجيهه إلى العملية باستخدام قاعدة الجدول adrr + T [٪ ds] .base . هذا يعني أنها ستأخذ عنوان طول الوحدة من نفس الجدول. لذلك في كل مرة تقوم فيها بالوصول إلى الذاكرة ، يكون لديها قاعدة بيانات لمحددات المقطع في شكل إدخالات جدول الواصف ، ويأخذ العنوان الذي تحدده ويطابقه مع طول المقطع المقابل.

الجمهور: فلماذا لا يتم استخدامه ، على سبيل المثال ، لحماية المخزن المؤقت؟

الأستاذ: نعم ، هذا سؤال جيد! هل يمكننا استخدام هذا للحماية من تجاوزات العازلة؟ على سبيل المثال ، لكل مخزن مؤقت لدينا ، يمكنك وضع قاعدة المخزن المؤقت هنا ، وهناك حجم المخزن المؤقت.

الجمهور: ماذا لو لم تكن بحاجة لوضعه في طاولة قبل أن تريد كتابته؟ لست بحاجة إلى أن تكون هناك باستمرار.

الأستاذ: نعم. لذلك ، أعتقد أن سبب عدم استخدام هذا النهج غالبًا للحماية من تجاوزات المخزن المؤقت هو أن عدد الإدخالات في هذا الجدول لا يمكن أن يتجاوز 2 في الدرجة السادسة عشرة ، لأن الواصفات يبلغ طولها 16 بت ، ولكن في الواقع في الواقع ، يتم استخدام عدد قليل من البتات لأشياء أخرى. لذلك في الواقع يمكنك فقط وضع 2 في القوة 13 من السجلات في هذا الجدول. لذلك ، إذا كان لديك في الكود الخاص بك صفيف من البيانات أكبر من 2 ¹³ ، فقد يحدث تجاوز في هذا الجدول.

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



بالمناسبة ، يستخدم Multex هذا النهج: يحتوي على 2 ¹⁸ سجلًا لأجزاء مختلفة و 2 ¹⁸ سجلًا للإزاحات المحتملة. وكل جزء من المكتبة العامة أو جزء من الذاكرة عبارة عن أجزاء منفصلة. يتم فحصها جميعًا للنطاق وبالتالي لا يمكن استخدامها على مستوى متغير.

الجمهور: من المفترض أن الحاجة المستمرة لاستخدام النواة سوف تبطئ العملية.

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

إذًا ، كم عدد هذه العناصر التي تستخدم فعليًا آلية التجزئة؟ يمكنك تخمين كيف يعمل. أعتقد ، بشكل افتراضي ، أن جميع هذه الأجزاء في x86 لها قاعدة تساوي 0 ، وطولها من 2 إلى 32. وبالتالي ، يمكنك الوصول إلى النطاق الكامل للذاكرة التي تريدها. لذلك ، بالنسبة لـ NaCl ، يقومون بترميز القاعدة 0 وتعيين الطول إلى 256 ميغابايت. ثم يشيرون إلى جميع سجلات 6 محددات المقطع في هذا السجل لمنطقة 256 ميجابايت. وبالتالي ، كلما وصلت المعدات إلى الذاكرة ، تقوم بتعديلها بإزاحة 256 ميجابايت. لذا ستقتصر القدرة على تغيير الوحدة على 256 ميجابايت.

أعتقد أنك تفهم الآن كيف يتم دعم هذا الجهاز وكيف يعمل ، لذلك قد ينتهي بك الأمر باستخدام محددات القطاعات هذه.
إذن ما الذي يمكن أن يحدث إذا نفذنا هذه الخطة فقط؟ هل يمكننا القفز من محدد المقطع في وحدة غير موثوق بها؟ أعتقد أن هناك شيء واحد يجب الانتباه إليه هو أن هذه السجلات مثل السجلات العادية ، ويمكنك نقل القيم إليها والخروج منها. لذلك ، يجب عليك التأكد من أن الوحدة غير الموثوق بها لا تشوه سجلات محدد القطع هذه. لأنه في مكان ما في جدول الواصف ، قد يكون هناك سجل ، وهو أيضًا واصف شريحة المصدر لعملية تحتوي على قاعدة 0 وطول يصل إلى 2 ³² .



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

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

الجمهور: هل يمكنك تهيئة الجدول بحيث يتم وضع طول صفري في جميع الفتحات غير المستخدمة؟

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

الجمهور: ما هو المطلوب لتغيير طول إخراج الجدول؟
أستاذ: يجب أن يكون لديك امتيازات الجذر. يحتوي Linux بالفعل على نظام يُدعى edit_ldt () لجدول الواصف المحلي ، والذي يسمح لأي عملية بتعديل جدوله الخاص ، أي أنه يوجد بالفعل جدول واحد لكل عملية. ولكن هذا الأمر أكثر تعقيدًا على منصة x86 ، فهناك جدول عالمي وجدول محلي. يمكن تغيير جدول محلي لعملية معينة.

الآن دعونا نحاول معرفة كيفية القفز والقفز من عملية تنفيذ Native Client أو القفز من وضع الحماية. ماذا يعني أن تقفز منا؟



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

ولكن بعد ذلك نحتاج إلى القفز بطريقة ما إلى وقت تشغيل موثوق به وإعادة تثبيت محددات المقطع إلى القيم الصحيحة لهذه الشريحة العملاقة ، والتي تغطي مساحة العنوان للعملية بأكملها - هذا النطاق من 0 إلى 2 ³² . ودعوا هذه الآليات الموجودة في الترامبولين " الترامبولين " وطلقات الانطلاق " العميل الأصلي ". إنهم يعيشون في وحدة 64k منخفضة. أروع شيء هو أن هذه "الترامبولين" و "القفزات" هي قطع من الكود تقع في 64 كيلو بايت السفلي من مساحة العملية. وهذا يعني أن هذه الوحدة غير الموثوقة يمكن أن تقفز إلى هناك ، لأنها عنوان رمز صالح ضمن حدود 32 بت و 256 ميجابايت. حتى تتمكن من القفز على هذا الترامبولين.

ولكن يجب على وقت تشغيل Native Client نسخ هذه "الترامبولين" من مكان ما بالخارج. وبالتالي ، لم يُسمح لوحدة Native Client بدعم رمز الترامبولين الخاص بها ، ويأتي رمز الترامبولين من وقت التشغيل الموثوق به . ونتيجة لذلك ، فإنه يحتوي بالفعل على كل هذه التعليمات الحساسة ، مثل نقل DS و CS وما إلى ذلك ، وهو ما لا يُسمح به للحصول على أكثر الكود غير موثوق به.

وبالتالي ، من أجل القفز من وضع الحماية إلى بيئة تشغيل موثوق بها ، للقيام بشيء مثل malos أو إنشاء خيط ، تحتاج إلى القفز إلى "الترامبولين" ، الذي "يعيش" في إزاحة 32 بايت.

, 4096 + 32 , . , , mov %ds, 7 , ds , 7 0 2 ³² . CS trusted service runtime , 256 .



, , , trusted service runtime , . , . DS , , , , - .

, ? , «»? , ?

: 64.

: , , . malo, 64, 32 . , , , .

, 32- , . , , 32 , 32- , . «» trusted runtime 32 .



. , , DS, CS . , 256- , trusted runtime , . .

«», trusted runtime 256 Native Client . «» DS , , mov %ds, 7 , , trusted runtime . . , «», - .

halt 32- «». «», . trusted service runtime , 1 .



trusted service runtime , , .

: «» ?

: «» 0 256 . 64- , , «», - -. Native Client .

: ?

: , ? , «»? ?

: , ?

: , - %eax , trusted runtime : «, »! EAX , mov , «» EAX , trusted runtime . , «»?

: , , . …

: , , — , , 0 2 ³² . . «», 256 .

, «», . , «» , . , «» .

: «» 256 ?

: , . , CS - . «», halt , mov, CS , , 256 .

, , «». , DS , , CS - .

, , x86 , Native Client .

, -.


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV من 249 دولارًا في هولندا والولايات المتحدة! اقرأ عن كيفية بناء مبنى البنية التحتية الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟