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

推荐订阅源

C
CXSECURITY Database RSS Feed - CXSecurity.com
Help Net Security
Help Net Security
P
Privacy International News Feed
S
Securelist
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
T
Tor Project blog
AWS News Blog
AWS News Blog
K
Kaspersky official blog
A
Arctic Wolf
Latest news
Latest news
T
Threat Research - Cisco Blogs
L
LINUX DO - 最新话题
P
Privacy & Cybersecurity Law Blog
Security Archives - TechRepublic
Security Archives - TechRepublic
Google DeepMind News
Google DeepMind News
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
月光博客
月光博客
N
News and Events Feed by Topic
Jina AI
Jina AI
博客园 - 司徒正美
WordPress大学
WordPress大学
罗磊的独立博客
雷峰网
雷峰网
AI
AI
Hugging Face - Blog
Hugging Face - Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
S
Security @ Cisco Blogs
博客园 - 三生石上(FineUI控件)
H
Heimdal Security Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
酷 壳 – CoolShell
酷 壳 – CoolShell
C
Cisco Blogs
博客园 - 【当耐特】
The Hacker News
The Hacker News
有赞技术团队
有赞技术团队
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
www.infosecurity-magazine.com
www.infosecurity-magazine.com
Schneier on Security
Schneier on Security
博客园 - Franky
S
SegmentFault 最新的问题
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Cloudbric
Cloudbric
爱范儿
爱范儿
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
S
Secure Thoughts
Last Week in AI
Last Week in AI
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Know Your Adversary
Know Your Adversary
Google DeepMind News
Google DeepMind News

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