惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

N
News | PayPal Newsroom
P
Proofpoint News Feed
Cyberwarzone
Cyberwarzone
C
Cisco Blogs
SecWiki News
SecWiki News
Know Your Adversary
Know Your Adversary
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Vercel News
Vercel News
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
罗磊的独立博客
NISL@THU
NISL@THU
WordPress大学
WordPress大学
Hacker News - Newest:
Hacker News - Newest: "LLM"
T
Threat Research - Cisco Blogs
AI
AI
Simon Willison's Weblog
Simon Willison's Weblog
Security Archives - TechRepublic
Security Archives - TechRepublic
有赞技术团队
有赞技术团队
L
LINUX DO - 热门话题
Hacker News: Ask HN
Hacker News: Ask HN
V
V2EX
G
GRAHAM CLULEY
TaoSecurity Blog
TaoSecurity Blog
Hugging Face - Blog
Hugging Face - Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
F
Fortinet All Blogs
博客园 - 叶小钗
博客园 - 三生石上(FineUI控件)
云风的 BLOG
云风的 BLOG
Recorded Future
Recorded Future
Latest news
Latest news
The Hacker News
The Hacker News
aimingoo的专栏
aimingoo的专栏
T
Troy Hunt's Blog
S
Schneier on Security
I
Intezer
Google DeepMind News
Google DeepMind News
A
Arctic Wolf
Apple Machine Learning Research
Apple Machine Learning Research
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
T
Threatpost
爱范儿
爱范儿
The Register - Security
The Register - Security
S
SegmentFault 最新的问题
Blog — PlanetScale
Blog — PlanetScale
博客园 - 聂微东
宝玉的分享
宝玉的分享
Recent Commits to openclaw:main
Recent Commits to openclaw:main
美团技术团队
B
Blog RSS Feed

Whexy Blog

We lost the AIxCC. So, what now? Arm VMM with Apple's Hypervisor Framework Driving WaveShare E‐Paper Display with a Raspberry Pi Pico in MicroPython Annual Hit Piece: Fuzzing Top Conference Paper Debunking Report Solving SSH Key Login Issues on Synology NAS Can SSD Cache Improve Synology NAS Write Speeds? Virtualization is all you need Running Windows Games on Mac Without Virtual Machines Tears of the Kingdom: End of an Era Anonymous CDN Traffic Relay Self-host Relay Service with CDN Home Networking Solution Building Your Own Blog System Connecting Smart Devices to SUSTech Campus Network Function Color Theory Stop Forkin' Around: Faster Creating of Large Processes on Linux PMU Interrupts: How to handle them Asynchronous Mutex Using QEMU to run Linux images on M1 Macbook Alligator In Vest - My first research work Experience Using Several Plugins in Complex LaTeX Projects Variance in Rust Understanding Rust Generic Traits SUSTeam: Ultimate Gaming Platform Inline Assembly Language in C React Learning Notes Building a School Bus Schedule App for Apple Watch 12307 Train Ticket Purchase Platform Sakai and Local Folder Synchronization Building a Super Simple OpenJudge in Two Nights Setting Up Remote Backup for macOS Shell Script for Automatically Logging into SUSTech Campus Network Building a Movie Streaming System in the Dorm
Use cgroup v2 inside docker containers
Whexy · 2024-05-02 · via Whexy Blog

In my recent endeavors, I've been conducting fuzzing experiments using Docker on a budget. My setup involves a few c6a.large EC2 instances from AWS, each equipped with 2 cores and 4GB of RAM. To optimize resource usage and manage costs, I execute my Docker containers with specific resource limits:

docker run -d --cpus=1.5 --memory=3.5g whexy/fuzztest:latest

I utilize BandFuzz, a collaborative fuzzing framework that can smartly resumes fuzzing tasks if they crash. However, I encountered a significant issue when the memory usage of a container exceeded 3.5GB. The Linux Out-Of-Memory (OOM) killer would terminate the entire container, including my vital auto-resume daemon.

My objective was clear: I needed the OOM killer to target only the fuzzers and spare the daemon. Initially, I attempted to bypass Docker's memory limits by managing cgroups directly. After some research and discussions (including insights from GPT), I tested the following command:

docker run -d --cpus=1.5 --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:rw whexy/fuzztest:latest

This approach allowed me to create a new cgroup via the filesystem interface. However, I hit a roadblock when I tried to add processes to cgroup.procs, encountering the frustrating error:

error: cgroup.procs: no such file or directory

Despite the file being visible, modifications were restricted.

Through further investigation, I discovered that Docker containers utilize a namespace that restricts control over the host's cgroup settings. To override this, the container must be launched with the --cgroupns=host flag, granting it the necessary privileges to interact directly with the host's cgroup settings.

Additionally, while exploring other related Docker arguments, I noted the --pid=host option. This setting aligns the container’s PID namespace with that of the host, facilitating direct checks on other cgroup.procs files using actual PIDs. This can be particularly useful for more intricate system interactions, although it was not necessary for my current setup.

By adjusting the Docker command to include --privileged --cgroupns=host, I was able to gain the control needed over cgroups within my containers, effectively isolating the OOM killer's impact to only the fuzzers, thereby safeguarding my auto-resume daemon. This setup proves crucial for maintaining the resilience and efficiency of my fuzzing experiments on a constrained budget.

© LICENSED UNDER CC BY-NC-SA 4.0