🔵 عنوان مقاله
What Makes System Calls Expensive: A Linux Internals Deep Dive (18 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چرا syscall در Linux گران است: عبور از مرز user به kernel باعث برهم‌زدن وضعیت ریزمعماری CPU می‌شود؛ از تخلیه pipeline و پاک‌سازی پیش‌بینی انشعاب تا به‌هم‌خوردن return stack buffer. در مسیر ورود/خروج syscall، kernel علاوه بر جابه‌جایی بین stack و گاه page table (در نتیجهٔ KPTI)، مجموعه‌ای از دفاع‌ها علیه حملات حدسی مثل Spectre را اعمال می‌کند؛ اقداماتی مانند IBPB/IBRS/STIBP، retpoline و RSB stuffing که همگی چرخه‌های اضافی مصرف می‌کنند. نتیجه این است که بخش بزرگی از هزینه، صرف خودِ تغییر سطح دسترسی و بازسازی بهینه‌سازی‌های CPU می‌شود، نه منطق اصلی kernel.
نمونهٔ روشن آن vDSO است که clock_gettime را در user-space فراهم می‌کند و بر اساس بنچمارک‌ها حدود ۸۹٪ سریع‌تر از نسخهٔ syscall عمل می‌کند؛ یعنی خودِ عبور به kernel گلوگاه اصلی است. پیام عملی برای توسعه‌دهندگان این است که در مسیرهای داغ از فراوانی syscall بکاهند: از vDSO برای زمان، batching و I/O برداری، و راهکارهایی مانند io_uring یا async I/O استفاده کنند و نتایج تکراری را cache نمایند. جمع‌بندی: هزینهٔ syscall بیشتر از برهم‌خوردن وضعیت ریزمعماری و ملاحظات امنیتی ورود/خروج ناشی می‌شود و پرهیز از این عبورها می‌تواند بهبود چشمگیری در کارایی ایجاد کند.
#Linux #Syscalls #Kernel #Performance #Microarchitecture #Spectre #vDSO #io_uring
🟣لینک مقاله:
https://blog.codingconfessions.com/p/what-makes-system-calls-expensive?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
What Makes System Calls Expensive: A Linux Internals Deep Dive (18 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چرا syscall در Linux گران است: عبور از مرز user به kernel باعث برهم‌زدن وضعیت ریزمعماری CPU می‌شود؛ از تخلیه pipeline و پاک‌سازی پیش‌بینی انشعاب تا به‌هم‌خوردن return stack buffer. در مسیر ورود/خروج syscall، kernel علاوه بر جابه‌جایی بین stack و گاه page table (در نتیجهٔ KPTI)، مجموعه‌ای از دفاع‌ها علیه حملات حدسی مثل Spectre را اعمال می‌کند؛ اقداماتی مانند IBPB/IBRS/STIBP، retpoline و RSB stuffing که همگی چرخه‌های اضافی مصرف می‌کنند. نتیجه این است که بخش بزرگی از هزینه، صرف خودِ تغییر سطح دسترسی و بازسازی بهینه‌سازی‌های CPU می‌شود، نه منطق اصلی kernel.
نمونهٔ روشن آن vDSO است که clock_gettime را در user-space فراهم می‌کند و بر اساس بنچمارک‌ها حدود ۸۹٪ سریع‌تر از نسخهٔ syscall عمل می‌کند؛ یعنی خودِ عبور به kernel گلوگاه اصلی است. پیام عملی برای توسعه‌دهندگان این است که در مسیرهای داغ از فراوانی syscall بکاهند: از vDSO برای زمان، batching و I/O برداری، و راهکارهایی مانند io_uring یا async I/O استفاده کنند و نتایج تکراری را cache نمایند. جمع‌بندی: هزینهٔ syscall بیشتر از برهم‌خوردن وضعیت ریزمعماری و ملاحظات امنیتی ورود/خروج ناشی می‌شود و پرهیز از این عبورها می‌تواند بهبود چشمگیری در کارایی ایجاد کند.
#Linux #Syscalls #Kernel #Performance #Microarchitecture #Spectre #vDSO #io_uring
🟣لینک مقاله:
https://blog.codingconfessions.com/p/what-makes-system-calls-expensive?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Codingconfessions
What Makes System Calls Expensive: A Linux Internals Deep Dive
An explanation of how Linux handles system calls on x86-64 and why they show up as expensive operations in performance profiles
🔵 عنوان مقاله
Linux Capabilities Revisited (4 minute read)
🟢 خلاصه مقاله:
امنیت در Linux با تقسیم قدرت‌های root به «capabilities» ظریف‌تر می‌شود، اما مهاجمان می‌توانند از همین سازوکار سوءاستفاده کنند: با setcap دادن قابلیتی مثل cap_setuid به یک باینری معمولی (مثلاً Python)، بدون نیاز به SUID به روت تبدیل می‌شوند و در نتیجه بک‌دوری پنهان می‌سازند. چون این مجوزها به‌صورت xattr روی inode و در security.capability ذخیره می‌شوند، در خروجی‌های معمولِ بررسی مجوزها به‌راحتی دیده نمی‌شوند و حتی بعد از rename یا ریبوت باقی می‌مانند. راهکار دفاعی این است که جست‌وجوی ارتقای دسترسی را از SUID/SGID فراتر ببریم: با getcap -r / همه قابلیت‌ها را فهرست کنیم، setcap و هر تغییر روی security.capability را مانیتور کنیم، فهرست سفید بسازیم، قابلیت‌های غیرضروری را با setcap -r حذف کنیم و این کنترل‌ها را در CI/CD و سخت‌سازی ایمیج‌ها بگنجانیم تا باینری‌های دارای capability ناخواسته وارد محیط نشوند.
#Linux #Capabilities #PrivilegeEscalation #setcap #SUID #BlueTeam #SecurityMonitoring #IncidentResponse
🟣لینک مقاله:
https://dfir.ch/posts/linux_capabilities/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Linux Capabilities Revisited (4 minute read)
🟢 خلاصه مقاله:
امنیت در Linux با تقسیم قدرت‌های root به «capabilities» ظریف‌تر می‌شود، اما مهاجمان می‌توانند از همین سازوکار سوءاستفاده کنند: با setcap دادن قابلیتی مثل cap_setuid به یک باینری معمولی (مثلاً Python)، بدون نیاز به SUID به روت تبدیل می‌شوند و در نتیجه بک‌دوری پنهان می‌سازند. چون این مجوزها به‌صورت xattr روی inode و در security.capability ذخیره می‌شوند، در خروجی‌های معمولِ بررسی مجوزها به‌راحتی دیده نمی‌شوند و حتی بعد از rename یا ریبوت باقی می‌مانند. راهکار دفاعی این است که جست‌وجوی ارتقای دسترسی را از SUID/SGID فراتر ببریم: با getcap -r / همه قابلیت‌ها را فهرست کنیم، setcap و هر تغییر روی security.capability را مانیتور کنیم، فهرست سفید بسازیم، قابلیت‌های غیرضروری را با setcap -r حذف کنیم و این کنترل‌ها را در CI/CD و سخت‌سازی ایمیج‌ها بگنجانیم تا باینری‌های دارای capability ناخواسته وارد محیط نشوند.
#Linux #Capabilities #PrivilegeEscalation #setcap #SUID #BlueTeam #SecurityMonitoring #IncidentResponse
🟣لینک مقاله:
https://dfir.ch/posts/linux_capabilities/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
dfir.ch
Linux Capabilities Revisited | dfir.ch
Technical blog by Stephan Berger (@malmoeb)