MAccConc

نظرة عامة

هذه أدوات لاستكشاف حالات التسابق (race conditions) في نواة Linux ولتنقيح النواة بشكل عام.

راجع أيضًا منشور المدونة الإعلاني https://projectzero.google/2026/09/maccconc-race-condition.html.

توجد حاليًا ثلاث أدوات:

1. واجهة رسومية (GUI) لعرض تتبعات KCOV لتنفيذ نواة Linux والوصول إلى الذاكرة، مع التركيز على التنفيذ المتزامن، ولإجبار ترتيبات تنفيذ محددة لحالات التسابق.
2. واجهة طرفية (TUI) تفعل الشيء نفسه، لكن بميزات أقل.
3. أداة لاختبار ترتيبات A-B-A المحتملة لحالة اختبار معينة تلقائيًا.

هذا ليس منتجًا من Google مدعومًا رسميًا. هذا المشروع غير مؤهل لـ برنامج مكافآت ثغرات البرمجيات مفتوحة المصدر من Google.

تعليمات البناء: النواة

أولاً، احصل على نسخة من LLVM تتضمن الالتزام dc5c6d008f48؛ أي إما بناء من HEAD، بدلاً من فرع إصدار، أو بناء بإصدار >=23. تتوفر مثل هذه البنيات، على سبيل المثال، من https://apt.llvm.org/ . إذا كنت من موظفي Google، راجع http://go/maccconc-kernel-build-notes .

احصل على شجرة نواة مع التصحيحات المطلوبة من https://github.com/thejh/linux ، الفرع kcov-tracing-full.

عند تكوين النواة وبنائها، اضبط متغيرات make CC / LLVM / LLVM_PREFIX كما هو موثق في https://docs.kernel.org/kbuild/llvm.html لضمان استخدام سلسلة أدوات LLVM الصحيحة.

اضبط متغير البيئة هذا للحصول على معلومات أوضح حول الكتل الأساسية المنفذة (للواجهة الرسومية) وتجنب مكدسات الاستدعاء المربكة بسبب تحسين استدعاء الذيل: export KCFLAGS="-fno-optimize-sibling-calls -mllvm -sanitizer-coverage-prune-blocks=false"

كوّن النواة كالمعتاد؛ قد يكون من المفيد البدء من make [...] kvm_guest.config إذا لم تكن تبدأ من تكوين موجود. تأكد من ضبط أعلام تكوين النواة التالية (على سبيل المثال من خلال واجهة تكوين ncurses make [...] nconfig أو بلصقها في أسفل .config):

# for core functionality
CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_KASAN=y
CONFIG_KASAN_OUTLINE=y
CONFIG_KCOV=y
CONFIG_KCOV_EXT_RECORDS=y
CONFIG_KCOV_MEMORY=y
CONFIG_KALLSYMS_ALL=y

# to give the GUI information about source lines and inlining
CONFIG_DEBUG_INFO_DWARF5=y

# for communicating with the GUI
CONFIG_VSOCKETS=y
CONFIG_VIRTIO_VSOCKETS=y
CONFIG_VIRTIO_PCI=y

# for maximizing the potential for race conditions
CONFIG_PREEMPT=y

# for making virtual addresses at runtime the same as in vmlinux
CONFIG_RANDOMIZE_BASE=n

# needed for several samples
CONFIG_TMPFS=y

يمكنك أيضًا تمكين ما يلي إذا كنت تريد اختبار حالات تسابق تتضمن RCU، لكن لاحظ أن هذا سيسبب تباطؤًا كبيرًا ولا يعمل حاليًا بشكل صحيح إلا مع الواجهة الرسومية.

CONFIG_RCU_EXPERT=y
CONFIG_RCU_STRICT_GRACE_PERIOD=y

يرجى التأكد من أن أي ميزات نواة تريد اختبارها مُجمَّعة داخل النواة، وليس كوحدات.

تعليمات البناء: أدوات مساحة المستخدم

يوصى ببناء أدوات مساحة المستخدم على الجهاز المضيف؛ خاصة الواجهة الرسومية، المصممة للعمل على المضيف، وليس في الضيف.

ثبّت git وتبعيات البناء؛ على Debian: sudo apt install git build-essential pkg-config libcapstone-dev libdw-dev libglfw3-dev

بعد استنساخ هذا المستودع، نزّل الوحدات الفرعية باستخدام: git submodule update --init --recursive

ابنِ باستخدام make.

إقلاع النواة المبنية

يمكنك إقلاع النواة المبنية في جهاز QEMU VM عادي إذا مكّنت أعلام تكوين النواة المطلوبة واستخدمت صورة قرص تحتوي على توزيعة Linux، أو شيء من هذا القبيل؛ لكن النهج الموصى به هو تثبيت kvmtool هكذا بدلاً من ذلك:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
cd kvmtool
make
make install

ثم يمكنك إقلاع النواة المبنية كما يلي (بافتراض أن $HOME/bin موجود في $PATH الخاص بك):

lkvm run --kernel [path to kernel tree]/arch/x86/boot/bzImage --vsock 5 --console virtio

سيمنحك هذا صدفة في بيئة حيث يتم تركيب عرض للقراءة فقط لنظام ملفات المضيف في /host، مع نظام ملفات جذر بسيط يتكون في الغالب من روابط رمزية إلى نظام ملفات المضيف هذا لـ /bin و/lib و/usr وما إلى ذلك. كل من / و/host هما نظاما ملفات 9p.

يرجى تركيب debugfs وtmpfs يدويًا في الضيف بعد كل إقلاع:

sh-5.3# mount -t debugfs none /sys/kernel/debug
sh-5.3# mount -t tmpfs none /tmp
sh-5.3#

كتابة حالات الاختبار وبناؤها

حالات الاختبار هي كود C يعرّف أربع دوال:

void test_setup(void) { [...] }
void test_thread1(void) { [...] }
void test_thread2(void) { [...] }
void test_end(void) { [...] }

لكل تنفيذ لحالة الاختبار، ستعمل test_setup() أولاً؛ ثم ستعمل test_thread1() وtest_thread2() بالتوازي؛ وأخيرًا، ستعمل test_end().

يجب بناء حالات الاختبار كمكتبات مشتركة، هكذا:

$ cc -shared -o [name].so [name].c -fPIC

يمكن أيضًا بناء حالات الاختبار النموذجية في مجلد testcase/ عبر make، هكذا:

$ make testcase/demo-dup-vs-close.so
cc -shared -o testcase/demo-dup-vs-close.so testcase/demo-dup-vs-close.c -Wall

اختبار ترتيبات A-B-A تلقائيًا

يمكن لأداة kcov-autorace استكشاف ترتيبات تنفيذ A-B-A تلقائيًا. ترتيبات A-B-A هي التي يعمل فيها الخيط A حتى نقطة معينة، ثم ينفذ الخيط B بالكامل، ثم يُكمل الخيط A تنفيذه.

بعد بناء حالة اختبار على المضيف، يمكنك تشغيلها في الضيف باستخدام مساعد kcov-autorace. على سبيل المثال:

sh-5.3# cd /host/{path to checkout on the host}
sh-5.3# ./kcov-autorace testcase/demo-dup-vs-close.so
loading kallsyms
RCU state (excluded): base=ffffffff82770100 len=500
loading testcase
initializing kcov
collecting A-B coverage
dup(5) = 6 (success)
testing candidates
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = -1 (Bad file descriptor)
dup(5) = 5 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
dup(5) = 6 (success)
stats:  injection-failed:0  wait-timeout:7  reordered:4
sh-5.3#

يوضح هذا وجود ترتيب A-B-A لـ close(5) وdup(5) يؤدي إلى إرجاع dup(5) للقيمة 5.

لاحظ أن kcov-autorace والأدوات الأخرى تستخدم مهلة انتظار دورانية مثبتة SPIN_LIMIT.

استكشاف حالات التسابق في الطرفية

يمكن استخدام أداة kcov-terminal لتشغيل حالة اختبار بقيود ترتيب محددة يدويًا. هذه لا تحدد ترتيبًا كاملاً؛ بدلاً من ذلك، هي مجموعة من قواعد "يجب أن يحدث A قبل B".

تُستخدم هذه الأداة في الضيف، بشكل مشابه لـ kcov-autorace.

مثال على الاستخدام مع حالة الاختبار demo-inode-attr-change للتشغيل بقيود ترتيب توضح أن قراءة UID وGID بواسطة fstat() ليست ذرية بالنسبة إلى fchown():

sh-5.3# ./kcov-terminal testcase/demo-inode-attr-change.so
uid=0 gid=0
=====  filtered to interference set, no RCU core  =====
LEGEND:
  type: R=read  W=write  M=modify(read+write)  F=free  A=atomic