نشانه‌های متنی پویا (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 در کجای سلسله‌مراتب دایرکتوری‌ها قرار گرفته باشد. این قابلیت ایجاد برنامه‌های مستقل و آماده اجرا را آسان می‌کند که نیازی به نصب در دایرکتوری‌های خاص ندارند و می‌توان آن‌ها را در هر دایرکتوری دلخواهی باز کرد و همچنان اشیاء اشتراکی خود را پیدا کنند.

$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، LOCALDOMAIN، LOCPATH، MALLOC_TRACE، NIS_PATH، NLSPATH، RESOLV_HOST_CONF، RES_OPTIONS، TMPDIR و TZDIR.

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

•

شناسه‌های کاربری واقعی و مؤثر (real and effective UID) فرآیند تفاوت داشته باشند، یا شناسه‌های گروهی واقعی و مؤثر (real and effective GID) متفاوت باشند. این وضعیت معمولاً در نتیجه اجرای برنامه‌های دارای بیت 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 را ارائه می‌دادند (که در این سیستم‌ها 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 اضافی و سفارشی کاربر که باید پیش از بقیه بارگذاری شوند. این قابلیت می‌تواند برای بازنویسی انتخابی توابع در سایر اشیاء اشتراکی به کار رود.

موارد فهرست می‌توانند با فاصله یا دونقطه از هم جدا شوند و هیچ راهکاری برای اسکیپ کردن جداکننده‌ها وجود ندارد. اشیاء با استفاده از قوانین ارائه‌شده در بخش توضیحات جستجو می‌شوند. اشیاء جستجو شده و به ترتیبی که از چپ به راست در فهرست مشخص شده است به نقشه پیوند افزوده می‌شوند.

در حالت اجرای امن، نام مسیرهای پیش‌بارگذاری حاوی اسلش نادیده گرفته می‌شوند. علاوه بر این، اشیاء اشتراکی تنها از دایرکتوری‌های جستجوی استاندارد و فقط در صورتی پیش‌بارگذاری می‌شوند که بیت حالت 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 در حالت اجرای امن نادیده گرفته می‌شود.

پیونددهنده پویا اشیاء اشتراکی حسابرسی را در نقاط بازرسی موسوم به نقاط حسابرسی (مثلاً بارگذاری یک شیء اشتراکی جدید، تفکیک یک نماد، یا فراخوانی نمادی از یک شیء اشتراکی دیگر) با فراخوانی تابع مناسب درون شیء اشتراکی حسابرسی مطلع می‌سازد. برای جزئیات، رجوع کنید به rtld-audit(7). رابط حسابرسی تا حد زیادی با رابط ارائه‌شده در Solaris سازگار است، آن‌چنان که در کتابچه راهنمای پیونددهنده و کتابخانه‌ها در فصل «رابط حسابرسی پیونددهنده زمان اجرا» توصیف شده است.

درون نام‌های مشخص‌شده در فهرست 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.4 تا 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)

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

از 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)

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

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

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

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

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)

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

برای نمونه در 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

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