نشانه‌های رشته‌ای پویا (Dynamic string tokens)

در چندین بخش، پیونددهنده پویا نشانه‌های رشته‌ای پویا را باز و جایگزین می‌کند:

•

در متغیرهای محیطی LD_LIBRARY_PATH، LD_PRELOAD و LD_AUDIT،

•

درون مقادیر تگ‌های بخش پویای DT_NEEDED، DT_RPATH، DT_RUNPATH، DT_AUDIT و DT_DEPAUDIT در باینری‌های ELF،

•

در آرگومان‌های گزینه‌های خط فرمان ld.so شامل --audit، --library-path و --preload (پایین را ببینید)، و

•

در آرگومان‌های نام فایل توابع dlopen(3) و dlmopen(3).

نشانه‌های جایگزین‌شده به شرح زیر هستند:

$ORIGIN (یا معادل آن ${ORIGIN})

این نشانه به دایرکتوری حاوی برنامه یا شیء مشترک گسترش می‌یابد. بنابراین، یک برنامه کاربردی مستقر در somedir/app می‌تواند با دستور زیر کامپایل شود:

gcc -Wl,-rpath,'$ORIGIN/../lib'

به طوری که شیء مشترک وابسته را در somedir/lib پیدا کند، بدون در نظر گرفتن اینکه somedir در کجای سلسله‌مراتب دایرکتوری‌ها واقع شده است. این امر ایجاد برنامه‌های کاربردی «آماده مصرف» (turn-key) را تسهیل می‌کند که نیازی به نصب در دایرکتوری‌های خاص ندارند، بلکه می‌توان آن‌ها را در هر دایرکتوری از حالت فشرده خارج کرد و همچنان اشیاء مشترک خود را بیابند.

$LIB (یا معادل آن ${LIB})

این نشانه بسته به معماری به lib یا lib64 گسترش می‌یابد (برای نمونه، در x86-64 به lib64 و در x86-32 به lib تبدیل می‌شود).

$PLATFORM (یا معادل آن ${PLATFORM})

این نشانه به رشته‌ای متناظر با نوع پردازنده سیستم میزبان گسترش می‌یابد (برای نمونه "x86_64"). در برخی معماری‌ها، هسته لینوکس رشته پلتفرم را در اختیار پیونددهنده پویا قرار نمی‌دهد. مقدار این رشته از مقدار AT_PLATFORM در بردار کمکی (auxiliary vector) گرفته می‌شود (به getauxval(3) مراجعه کنید).

توجه داشته باشید که نشانه‌های رشته‌ای پویا هنگام مقداردهی از طریق پوسته باید به درستی نقل‌قول (کوتیشن) شوند تا از باز شدن آن‌ها به عنوان متغیرهای پوسته یا محیطی جلوگیری به عمل آید.

حالت اجرای امن (Secure-execution mode)

به دلایل امنیتی، اگر پیونددهنده پویا تشخیص دهد که یک باینری باید در حالت اجرای امن اجرا شود، اثرات برخی از متغیرهای محیطی باطل یا تعدیل می‌شوند، و علاوه بر این، آن متغیرهای محیطی از محیط زدوده می‌شوند تا برنامه حتی تعاریف آن‌ها را نبیند. برخی از این متغیرهای محیطی بر عملکرد خود پیونددهنده پویا اثر می‌گذارند و در زیر شرح داده شده‌اند. سایر متغیرهای محیطی که با این روش رفتار می‌شوند عبارتند از: GCONV_PATH، GETCONF_DIR، HOSTALIASES، LOCALDOMAIN، LD_AUDIT، LD_DEBUG، LD_DEBUG_OUTPUT، LD_DYNAMIC_WEAK، LD_HWCAP_MASK، LD_LIBRARY_PATH، LD_ORIGIN_PATH، LD_PRELOAD، LD_PROFILE، LD_SHOW_AUXV، LOCPATH، MALLOC_TRACE، NIS_PATH، NLSPATH، RESOLV_HOST_CONF، RES_OPTIONS، TMPDIR و TZDIR.

یک باینری در صورتی در حالت اجرای امن اجرا می‌شود که ورودی AT_SECURE در بردار کمکی (auxiliary vector؛ به getauxval(3) مراجعه کنید) مقداری غیرصفر داشته باشد. این ورودی ممکن است به دلایل گوناگونی مقدار غیرصفر داشته باشد، از جمله:

•

شناسه‌های کاربری واقعی و مؤثر فرایند متفاوت باشند، یا شناسه‌های گروهی واقعی و مؤثر متفاوت باشند. این وضعیت معمولاً در نتیجه اجرای برنامه‌ای با پرچم set-user-ID یا set-group-ID رخ می‌دهد.

•

فرایندی با شناسه کاربری غیرریشه، باینری‌ای را اجرا کند که قابلیت‌هایی (capabilities) به فرایند اعطا می‌کند.

•

یک مقدار غیرصفر ممکن است توسط یک ماژول امنیتی لینوکس (LSM) تنظیم شده باشد.

متغیرهای محیطی (Environment variables)

در میان مهم‌ترین متغیرهای محیطی، موارد زیر قرار دارند:

LD_ASSUME_KERNEL (از glibc 2.2.3 تا glibc 2.36)

هر شیء مشترک می‌تواند به پیونددهنده پویا حداقل نسخه ABI هسته مورد نیاز خود را اعلام کند. (این نیاز در یک بخش یادداشت ELF کدگذاری شده که با readelf -n به عنوان بخشی با برچسب NT_GNU_ABI_TAG قابل مشاهده است). در زمان اجرا، پیونددهنده پویا نسخه ABI هسته در حال اجرا را تعیین کرده و از بارگذاری اشیاء مشترکی که حداقل نسخه ABI آن‌ها بیشتر از نسخه هسته جاری باشد خودداری می‌کند.

متغیر LD_ASSUME_KERNEL می‌تواند برای این استفاده شود که پیونددهنده پویا فرض کند روی سیستمی با نسخه ABI هسته متفاوت در حال اجراست. برای نمونه، خط فرمان زیر باعث می‌شود پیونددهنده پویا هنگام بارگذاری اشیاء مشترک مورد نیاز myprog فرض کند روی لینوکس 2.2.5 اجرا می‌شود:

$ LD_ASSUME_KERNEL=2.2.5 ./myprog

روی سیستم‌هایی که نسخه‌های متعددی از یک شیء مشترک (در دایرکتوری‌های مختلف در مسیر جستجو) ارائه می‌دهند که الزامات نسخه ABI هسته متفاوتی دارند، متغیر LD_ASSUME_KERNEL می‌تواند برای انتخاب نسخه شیء مورد استفاده (بسته به ترتیب جستجوی دایرکتوری) به کار رود.

از نظر تاریخی، متداول‌ترین کاربرد LD_ASSUME_KERNEL انتخاب دستی پیاده‌سازی قدیمی‌تر ریسمان‌های پازیکس LinuxThreads روی سیستم‌هایی بود که هر دو پیاده‌سازی LinuxThreads و NPTL را ارائه می‌دادند (که دومی به طور معمول روی چنین سیستم‌هایی پیش‌فرض بود)؛ به pthreads(7) مراجعه کنید.

LD_BIND_NOW (از glibc 2.1.1)

اگر روی یک رشته غیرخالی تنظیم شود، باعث می‌شود پیونددهنده پویا تمام نمادها را در زمان راه‌اندازی برنامه حل‌وفصل کند، به جای اینکه حل‌وفصل فراخوانی توابع را به زمان ارجاع اولیه آن‌ها موکول نماید. این گزینه هنگام استفاده از یک اشکال‌زدا (debugger) مفید است.

LD_LIBRARY_PATH

فهرستی از دایرکتوری‌ها که در زمان اجرا برای کتابخانه‌های ELF در آن‌ها جستجو می‌شود. موارد موجود در فهرست با دونقطه (:) یا نقطه‌ویرگول (;) از یکدیگر جدا می‌شوند و هیچ پشتیبانی برای اسکیپ کردن این جداکننده‌ها وجود ندارد. یک نام دایرکتوری با طول صفر نشان‌دهنده دایرکتوری کاری جاری است.

این متغیر در حالت اجرای امن نادیده گرفته می‌شود.

درون نام مسیرهای مشخص‌شده در LD_LIBRARY_PATH، پیونددهنده پویا نشانه‌های $ORIGIN، $LIB و $PLATFORM (یا نسخه‌های دارای آکولاد در اطراف نام‌ها) را همان‌گونه که در بالا در بخش نشانه‌های رشته‌ای پویا شرح داده شد باز می‌کند. بنابراین، برای نمونه، دستور زیر باعث می‌شود کتابخانه در یکی از زیردایرکتوری‌های lib یا lib64 زیر دایرکتوری حاوی برنامه اجرایی جستجو شود:

$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog

(به استفاده از نقل‌قول تکی توجه کنید که مانع از باز شدن $ORIGIN و $LIB به عنوان متغیرهای پوسته می‌شود!)

LD_PRELOAD

فهرستی از اشیاء مشترک ELF اضافی مشخص‌شده توسط کاربر که باید پیش از تمام اشیاء دیگر بارگذاری شوند. این ویژگی می‌تواند برای بازنویسی و جایگزینی انتخابی توابع در سایر اشیاء مشترک استفاده شود.

موارد موجود در فهرست می‌توانند با فاصله یا دونقطه از یکدیگر جدا شوند و هیچ پشتیبانی برای اسکیپ کردن جداکننده‌ها وجود ندارد. اشیاء با استفاده از قواعد ارائه‌شده در بخش «توضیحات» جستجو می‌شوند. اشیاء به ترتیب از چپ به راست مشخص‌شده در فهرست جستجو شده و به نقشه پیوند (link map) افزوده می‌شوند.

در حالت اجرای امن، مسیرهای پیش‌بارگذاری حاوی اسلش نادیده گرفته می‌شوند. علاوه بر این، اشیاء مشترک تنها از دایرکتوری‌های جستجوی استاندارد و تنها در صورتی بارگذاری می‌شوند که بیت حالت set-user-ID آن‌ها فعال باشد (که این امر معمول نیست).

در میان نام‌های مشخص‌شده در فهرست LD_PRELOAD، پیونددهنده پویا نشانه‌های $ORIGIN، $LIB و $PLATFORM (یا نسخه‌های دارای آکولاد) را طبق توضیحات بخش نشانه‌های رشته‌ای پویا درک می‌کند. (همچنین بحث نقل‌قول در توضیحات LD_LIBRARY_PATH را ببینید).

روش‌های گوناگونی برای تعیین کتابخانه‌های پیش‌بارگذاری وجود دارد که به ترتیب زیر پردازش می‌شوند:

LD_TRACE_LOADED_OBJECTS

اگر تنظیم شود (روی هر مقداری)، باعث می‌شود برنامه به جای اجرای عادی، وابستگی‌های پویای خود را مانند زمانی که توسط ldd(1) اجرا می‌شود فهرست کند.

سپس تعداد زیادی متغیر با کاربرد کمتر یا مبهم‌تر وجود دارد که بسیاری از آن‌ها منسوخ شده یا تنها برای مصارف داخلی هستند:

LD_AUDIT (از glibc 2.4)

فهرستی از اشیاء مشترک ELF تعیین‌شده توسط کاربر که باید قبل از همه اشیاء دیگر در یک فضای نام پیونددهنده مجزا بارگذاری شوند (یعنی فضایی که در پیوندهای معمول نمادها که در فرایند رخ می‌دهد تداخلی ایجاد نمی‌کند). این اشیاء می‌توانند برای حسابرسی عملکرد پیونددهنده پویا استفاده شوند. موارد موجود در فهرست با دونقطه از هم جدا می‌شوند و راهی برای اسکیپ جداکننده وجود ندارد.

متغیر LD_AUDIT در حالت اجرای امن نادیده گرفته می‌شود.

پیونددهنده پویا، اشیاء مشترک حسابرسی را در نقاط بازرسی به اصطلاح حسابرسی (auditing checkpoints) مطلع می‌سازد—برای نمونه بارگذاری یک شیء مشترک جدید، حل‌وفصل یک نماد، یا فراخوانی یک نماد از شیء مشترک دیگر—از طریق فراخوانی تابعی مناسب در شیء مشترک حسابرس. برای جزئیات به rtld-audit(7) مراجعه کنید. رابط حسابرسی تا حد زیادی با آنچه در سولاریس ارائه شده سازگار است، همان‌طور که در Linker and Libraries Guide آن، در فصل Runtime Linker Auditing Interface توصیف شده است.

در میان نام‌های مشخص‌شده در فهرست LD_AUDIT، پیونددهنده پویا نشانه‌های $ORIGIN، $LIB و $PLATFORM (یا نسخه‌های دارای آکولاد) را درک می‌کند.

از نسخه glibc 2.13، در حالت اجرای امن، نام‌های موجود در فهرست حسابرسی که حاوی اسلش هستند نادیده گرفته می‌شوند و تنها اشیاء مشترکی در دایرکتوری‌های جستجوی استاندارد بارگذاری می‌شوند که بیت حالت set-user-ID در آن‌ها فعال باشد.

LD_BIND_NOT (از glibc 2.1.95)

اگر این متغیر محیطی روی یک رشته غیرخالی تنظیم شود، پس از حل‌وفصل نماد یک تابع، جدول‌های GOT (جدول آفست سراسری) و PLT (جدول پیوند رویه) را به‌روزرسانی نمی‌کند. با ترکیب این متغیر و LD_DEBUG (با دسته‌های bindings و symbols)، می‌توان تمام پیوندهای تابعی زمان اجرا را مشاهده کرد.

LD_DEBUG (از glibc 2.1)

اطلاعات اشکال‌زدایی با جزئیات کامل درباره عملکرد پیونددهنده پویا تولید می‌کند. محتوای این متغیر شامل یک یا چند دسته از دسته‌های زیر است که با دونقطه، کاما یا (اگر مقدار نقل‌قول شده باشد) فاصله از هم جدا می‌شوند:

از glibc 2.3.4، متغیر LD_DEBUG در حالت اجرای امن نادیده گرفته می‌شود، مگر اینکه فایل /etc/suid-debug وجود داشته باشد (محتوای فایل بی‌اهمیت است).

LD_DEBUG_OUTPUT (از glibc 2.1)

به صورت پیش‌فرض، خروجی LD_DEBUG در خطای استاندارد نوشته می‌شود. اگر LD_DEBUG_OUTPUT تعریف شده باشد، خروجی در نام مسیر مشخص‌شده توسط مقدار آن نوشته می‌شود، به همراه پسوند «.» (نقطه) و شناسه فرایند (PID) که به انتهای نام مسیر افزوده می‌شود.

متغیر LD_DEBUG_OUTPUT در حالت اجرای امن نادیده گرفته می‌شود.

LD_DYNAMIC_WEAK (از glibc 2.1.91)

به طور پیش‌فرض، هنگام جستجو در کتابخانه‌های مشترک برای حل‌وفصل ارجاع یک نماد، پیونددهنده پویا به اولین تعریفی که می‌یابد پیوند می‌دهد.

نسخه‌های قدیمی glibc (پیش از glibc 2.2) رفتار متفاوتی داشتند: اگر پیونددهنده نمادی را می‌یافت که ضعیف (weak) بود، آن نماد را به خاطر می‌سپرد و به جستجو در سایر کتابخانه‌های مشترک ادامه می‌داد. اگر متعاقباً تعریف قوی (strong) از همان نماد پیدا می‌کرد، از آن تعریف استفاده می‌نمود. (اگر نماد دیگری پیدا نمی‌شد، پیونددهنده از همان نماد ضعیفی که در ابتدا یافته بود استفاده می‌کرد).

رفتار قدیمی glibc غیراستاندارد بود. (رویه استاندارد این است که تمایز بین نمادهای ضعیف و قوی فقط باید در زمان پیونددهی ایستا اثر داشته باشد). در glibc 2.2، پیونددهنده پویا برای ارائه رفتار فعلی اصلاح شد (که رفتاری بود که بیشتر پیاده‌سازی‌های دیگر در آن زمان ارائه می‌دادند).

تعریف متغیر محیطی LD_DYNAMIC_WEAK (با هر مقداری) رفتار قدیمی (غیراستاندارد) glibc را فراهم می‌کند، که به موجب آن یک نماد ضعیف در یک کتابخانه مشترک ممکن است توسط یک نماد قوی که بعداً در کتابخانه مشترک دیگری کشف می‌شود بازنویسی شود. (توجه داشته باشید حتی زمانی که این متغیر تنظیم شده باشد، یک نماد قوی در یک کتابخانه مشترک، تعریف ضعیف همان نماد در برنامه اصلی را بازنویسی نخواهد کرد).

از glibc 2.3.4، متغیر LD_DYNAMIC_WEAK در حالت اجرای امن نادیده گرفته می‌شود.

LD_HWCAP_MASK (از glibc 2.1 تا glibc 2.38)

ماسک قابلیت‌های سخت‌افزاری. از glibc 2.26، در صورتی که glibc از قابلیت tunables پشتیبانی نکند این گزینه ممکن است نادیده گرفته شود.

LD_ORIGIN_PATH (از glibc 2.1)

مسیری که باینری در آن قرار دارد.

از glibc 2.4، متغیر LD_ORIGIN_PATH در حالت اجرای امن نادیده گرفته می‌شود.

LD_POINTER_GUARD (از glibc 2.5 تا glibc 2.22)

تنظیم روی 0 حفاظت از اشاره‌گر (pointer guarding) را غیرفعال می‌کند. هر مقدار دیگری حفاظت از اشاره‌گر را فعال می‌سازد که حالت پیش‌فرض نیز هست. حفاظت از اشاره‌گر یک سازوکار امنیتی است که به موجب آن برخی از اشاره‌گرهای کد ذخیره‌شده در حافظه قابل نوشتن برنامه (آدرس‌های بازگشت ذخیره‌شده توسط setjmp(3) یا اشاره‌گرهای تابع مورد استفاده توسط بخش‌های داخلی glibc) به صورت شبه‌تصادفی دستکاری (mangle) می‌شوند تا ربودن این اشاره‌گرها برای مهاجم در صورت بروز سرریز بافر یا حمله تخریب پشته دشوارتر شود. از glibc 2.23، دیگر نمی‌توان از LD_POINTER_GUARD برای غیرفعال کردن حفاظت اشاره‌گر استفاده کرد و این قابلیت اکنون همیشه فعال است.

LD_PROFILE (از glibc 2.1)

نام یک شیء مشترک (منفرد) برای پروفایل‌گیری، که به صورت یک نام مسیر یا soname مشخص می‌شود. خروجی پروفایل‌گیری به فایلی با این نام افزوده می‌شود: $LD_PROFILE_OUTPUT/$LD_PROFILE.profile.

از glibc 2.2.5، متغیر LD_PROFILE در حالت اجرای امن از مسیر پیش‌فرض متفاوتی استفاده می‌کند.

LD_PROFILE_OUTPUT (از glibc 2.1)

دایرکتوری که خروجی LD_PROFILE باید در آن نوشته شود. اگر این متغیر تعریف نشده باشد یا به صورت یک رشته خالی باشد، مقدار پیش‌فرض /var/tmp است.

متغیر LD_PROFILE_OUTPUT در حالت اجرای امن نادیده گرفته می‌شود؛ در عوض همیشه از /var/profile استفاده می‌شود.

LD_SHOW_AUXV (از glibc 2.1)

اگر این متغیر محیطی تعریف شده باشد (با هر مقداری)، آرایه کمکی ارسال‌شده از سوی هسته را نشان می‌دهد (همچنین به getauxval(3) مراجعه کنید).

از glibc 2.3.4، متغیر LD_SHOW_AUXV در حالت اجرای امن نادیده گرفته می‌شود.

LD_TRACE_PRELINKING (از glibc 2.4 تا glibc 2.35)

اگر این متغیر محیطی تعریف شود، پیش‌پیونددهی (prelinking) شیئی که نامش به این متغیر اختصاص یافته است را ردگیری می‌کند. (از ldd(1) برای دریافت فهرستی از اشیایی که ممکن است ردگیری شوند استفاده کنید). اگر نام شیء شناخته نشود، تمام فعالیت‌های پیش‌پیونددهی ردگیری می‌شوند.

LD_USE_LOAD_BIAS (از glibc 2.3.3 تا glibc 2.35)

به طور پیش‌فرض (یعنی اگر این متغیر تعریف نشده باشد)، فایل‌های اجرایی و اشیاء مشترک پیش‌پیوندیافته آدرس‌های پایه اشیاء مشترک وابسته خود را محترم می‌شمارند و فایل‌های اجرایی مستقل از موقعیت غیرپیش‌پیوندیافته (PIEs) و سایر اشیاء مشترک آن‌ها را محترم نمی‌شمارند. اگر LD_USE_LOAD_BIAS با مقدار 1 تعریف شود، هم فایل‌های اجرایی و هم PIEها آدرس‌های پایه را محترم می‌شمارند. اگر با مقدار 0 تعریف شود، هیچ‌کدام آدرس‌های پایه را رعایت نمی‌کنند.

از glibc 2.3.3، این متغیر در حالت اجرای امن نادیده گرفته می‌شود.

LD_VERBOSE (از glibc 2.1)

اگر روی یک رشته غیرخالی تنظیم شود، در صورتی که متغیر محیطی LD_TRACE_LOADED_OBJECTS تنظیم شده باشد، اطلاعات نسخه‌بندی نمادها را درباره برنامه نمایش می‌دهد.

LD_WARN (از glibc 2.1.3)

اگر روی یک رشته غیرخالی تنظیم شود، درباره نمادهای حل‌وفصل‌نشده هشدار می‌دهد.

LD_PREFER_MAP_32BIT_EXEC (فقط x86-64؛ از glibc 2.23)

بر اساس راهنمای بهینه‌سازی نرم‌افزار اینتل Silvermont، برای برنامه‌های کاربردی ۶۴بیتی، هنگامی که هدف یک پرش (branch) بیش از ۴ گیگابایت از شاخه فاصله داشته باشد، عملکرد پیش‌بینی پرش می‌تواند تأثیر منفی ببیند. اگر این متغیر محیطی تنظیم شود (روی هر مقداری)، پیونددهنده پویا ابتدا سعی می‌کند صفحات اجرایی را با استفاده از فلگ MAP_32BIT در تابع mmap(2) نگاشت کند، و در صورت شکست آن تلاش، به نگاشت بدون آن فلگ بازمی‌گردد. توجه: فلگ MAP_32BIT نگاشت را در ۲ گیگابایت پایینی (نه ۴ گیگابایت) فضای آدرس انجام می‌دهد.

از آنجا که MAP_32BIT دامنه آدرس موجود برای تصادفی‌سازی چیدمان فضای آدرس (ASLR) را کاهش می‌دهد، LD_PREFER_MAP_32BIT_EXEC همیشه در حالت اجرای امن غیرفعال است.

قابلیت‌های سخت‌افزاری قدیمی (از glibc 2.5 تا glibc 2.37)

برخی از اشیاء مشترک با استفاده از دستورالعمل‌های خاص سخت‌افزار کامپایل می‌شوند که در هر پردازنده‌ای وجود ندارد. چنین اشیایی باید در دایرکتوری‌هایی نصب شوند که نام آن‌ها قابلیت‌های سخت‌افزاری مورد نیاز را مشخص می‌کند، مانند /usr/lib/sse2. پیونددهنده پویا این دایرکتوری‌ها را با سخت‌افزار دستگاه بررسی می‌کند و مناسب‌ترین نسخه از یک شیء مشترک را برمی‌گزیند. دایرکتوری‌های قابلیت سخت‌افزاری می‌توانند برای ترکیب ویژگی‌های CPU آبشاری (cascade) شوند. فهرست نام قابلیت‌های سخت‌افزاری پشتیبانی‌شده به نوع پردازنده بستگی دارد. نام‌های زیر در حال حاضر شناخته شده‌اند:

Alpha

ev4, ev5, ev56, ev6, ev67

MIPS

loongson2e, loongson2f, octeon, octeon2

PowerPC

4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle, fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601, ppc64, smt, spe, ucache, vsx

SPARC

flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2

s390

dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle, z900, z990, z9-109, z10, zarch

x86 (فقط ۳۲بیتی)

acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm

پشتیبانی از قابلیت‌های سخت‌افزاری قدیمی این اشکال را دارد که با افزودن هر ویژگی جدید، مسیر جستجو به صورت نمایی رشد می‌کند، چرا که باید به هر ترکیبی از دیگر ویژگی‌های موجود اضافه شود.

برای نمونه در x86 ۳۲بیتی، اگر سخت‌افزار از i686 و sse2 پشتیبانی کند، مسیر جستجوی حاصل i686/sse2:i686:sse2:. خواهد بود. یک قابلیت جدید newcap مسیر جستجو را به newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:. تنظیم خواهد کرد.

قابلیت‌های سخت‌افزاری glibc (از glibc 2.33)

نسخه 2.33 glibc یک طرح قابلیت سخت‌افزاری جدید اضافه کرد که در آن تحت هر معماری CPU، سطوح مشخصی می‌توانند تعریف شوند و پشتیبانی از ویژگی‌های خاص یا دستورالعمل‌های ویژه را گروه‌بندی کنند. هر سطح معماری مجموعه ثابتی از مسیرها دارد که بسته به سخت‌افزار دستگاه، به فهرست جستجوی پیونددهنده پویا اضافه می‌کند. از آنجا که هر سطح معماری جدید با سطوح موجود قبلی ترکیب نمی‌شود، طرح جدید نقص رشد مهارنشدنی فهرست جستجوی پیونددهنده پویا را ندارد.

برای نمونه در x86 ۶۴بیتی، اگر سخت‌افزار از x86_64-v3 پشتیبانی کند (برای نمونه Intel Haswell یا AMD Excavator)، مسیر جستجوی حاصل glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. خواهد بود.

مسیرهای زیر در حال حاضر به ترتیب اولویت پشتیبانی می‌شوند:

PowerPC (فقط ۶۴بیتی little-endian)

power10, power9

s390 (فقط ۶۴بیتی)

z16, z15, z14, z13

x86 (فقط ۶۴بیتی)

x86-64-v4, x86-64-v3, x86-64-v2

نسخه 2.37 glibc پشتیبانی از قابلیت‌های سخت‌افزاری قدیمی را حذف کرد.