صاحب libsodium: إضافة سطر لمسح السر من الذاكرة قد تترك نسخًا منه أكثر من قبل
المغزى: كود المسح الذي يبدو صحيحًا في المراجعة قد لا يمس السر أصلًا، لأن ما يحدث للقيمة يقرره المترجم لا الكود المكتوب، والـ LLMs تقترح هذا النوع من التعديلات بكثرة.
نشر Frank Denis، صاحب مكتبة التشفير libsodium، في 6 أكتوبر 2026 الجزء الأول من سلسلة عن zeroization، أي مسح الأسرار مثل المفاتيح وكلمات المرور من الذاكرة بعد استخدامها. وخلاصته أن “إضافة مسح لسر ما قد تترك نسخًا منه أكثر مما تركه الكود الأصلي”.
والمشكلة الأولى معروفة. فحين يُستدعى memset لتصفير متغير مؤقت قبل الخروج من الدالة، يلاحظ المترجم أن هذا المتغير لن يُقرأ بعد ذلك، فيحذف السطر عند التحسين. وتخرج التعليمات نفسها بوجود المسح وبدونه.
والحل الشائع هو الكتابة بايتًا بايتًا عبر مؤشر volatile، وهي كتابة لا يستطيع المترجم حذفها. وقد طبّقه Denis ونظر في المخرَج على معمارية arm64 باستخدام Clang 21. فوجد ثماني تعليمات strb تكتب أصفارًا فعلًا.
لكن لم تكن هناك أي تعليمة وضعت السر في تلك المواضع من الأساس. فالقيمة لم تُكتب في الذاكرة قط، بل بقيت في المسجّل x8. أي أن الكود كتب أصفارًا في مواضع لم يدخلها السر، وبقي السر نفسه في المسجّل. والنتيجة تعليمات إضافية لا تمسح شيئًا، مع شعور زائف بالأمان. وكل الأمثلة منشورة على Godbolt.
ويشير Denis صراحة إلى أن هذا النوع من التعديلات “يحبه الـ LLMs” لسهولة اقتراحه. فقد يصل إلى المشروع pull request يضيف مسحًا لكل ما يشبه السر، ويبدو سليمًا عند المراجعة، بينما لا يفعل شيئًا. وهذا يعني أن مراجعة الكود المصدري وحده لا تكفي في هذه الحالة، لأن السؤال الحقيقي هو أين انتهى السر في المخرَج، وهل وصل إلى الذاكرة أصلًا.
ولم تقدم التدوينة حلًا نهائيًا بعد، لأنها الجزء الأول من السلسلة، وما زال ما ستقترحه الأجزاء التالية غير معروف.