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

推荐订阅源

博客园 - 三生石上(FineUI控件)
Martin Fowler
Martin Fowler
月光博客
月光博客
AI
AI
B
Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
C
CXSECURITY Database RSS Feed - CXSecurity.com
WordPress大学
WordPress大学
GbyAI
GbyAI
L
Lohrmann on Cybersecurity
O
OpenAI News
Schneier on Security
Schneier on Security
P
Palo Alto Networks Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
T
Troy Hunt's Blog
V2EX - 技术
V2EX - 技术
W
WeLiveSecurity
L
LINUX DO - 最新话题
人人都是产品经理
人人都是产品经理
S
Security Affairs
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
A
Arctic Wolf
Recorded Future
Recorded Future
Microsoft Security Blog
Microsoft Security Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
G
GRAHAM CLULEY
N
Netflix TechBlog - Medium
TaoSecurity Blog
TaoSecurity Blog
C
Check Point Blog
Scott Helme
Scott Helme
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Apple Machine Learning Research
Apple Machine Learning Research
PCI Perspectives
PCI Perspectives
www.infosecurity-magazine.com
www.infosecurity-magazine.com
Vercel News
Vercel News
The Hacker News
The Hacker News
Y
Y Combinator Blog
Latest news
Latest news
SecWiki News
SecWiki News
Hugging Face - Blog
Hugging Face - Blog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Google Online Security Blog
Google Online Security Blog
Webroot Blog
Webroot Blog
Google DeepMind News
Google DeepMind News
Recent Commits to openclaw:main
Recent Commits to openclaw:main
C
Cisco Blogs
博客园_首页
H
Hackread – Cybersecurity News, Data Breaches, AI and More
宝玉的分享
宝玉的分享
L
LINUX DO - 热门话题

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