meniOS is a hobby operating system kernel written in C and Assembly for the x86-64 architecture. As an educational and experimental OS project with the goal of running Doom in userland, security considerations are approached from both a learning perspective and responsible development practices.

Important Note: meniOS is currently in active development and not intended for production use. It is designed for educational purposes, experimentation, and the specific goal of running Doom in a custom userland environment.

Currently, meniOS follows a rolling development model on the trunk branch. Security updates are applied to the latest development version.

For an operating system kernel, even in a hobby context, we take the following security concerns seriously:

• Buffer overflows and underflows
• Use-after-free vulnerabilities
• Double-free errors
• Integer overflow/underflow leading to memory corruption
• Stack overflow vulnerabilities
• Null pointer dereferences in critical paths

• Improper user/kernel boundary enforcement
• Syscall parameter validation failures
• Ring 3 to Ring 0 privilege escalation vectors
• Memory permission bypass vulnerabilities

• Kernel memory leaks to userspace
• Uninitialized memory exposure
• Side-channel information leaks
• Debug information exposure in release builds

• Memory allocation/deallocation issues
• Resource exhaustion vulnerabilities
• Infinite loops or excessive CPU consumption
• Deadlock conditions in kernel code

• Malformed ELF file processing (once ELF loader is implemented)
• Syscall parameter validation
• Hardware input validation (keyboard, etc.)
• Boot parameter validation

Given meniOS's current development status and educational nature:

• Cryptographic implementations (not yet implemented)
• Network security (no network stack implemented)
• Filesystem security (VFS not yet implemented)
• Multi-user security (single-user system currently)
• Hardware security features (not yet utilizing advanced CPU security features)

If you discover a security vulnerability in meniOS, we appreciate responsible disclosure. Please follow these steps:

• Email: pbalduino [at] gmail [dot] com
• Subject: "[SECURITY] meniOS Vulnerability Report"
• Encryption: If you have security concerns about email communication, please indicate this in your initial contact

Please provide as much detail as possible:

Vulnerability Details:
- Component affected (memory management, syscalls, drivers, etc.)
- Vulnerability type (buffer overflow, privilege escalation, etc.)
- Potential impact and severity assessment
- Steps to reproduce the issue
- Proof of concept code (if applicable)
- Suggested mitigation or fix (if known)

Environment:
- meniOS version/commit hash
- Build configuration
- Testing environment (QEMU, real hardware)
- Compiler version and flags used

As a hobby project with limited maintainer resources:

• Initial acknowledgment: Within 7 days
• Initial assessment: Within 14 days
• Fix development: Timeframe varies based on complexity
• Public disclosure: After fix is implemented and tested

We request that you:

• Give us reasonable time to investigate and fix the issue
• Do not publicly disclose the vulnerability until we've had a chance to address it
• Do not exploit the vulnerability for malicious purposes
• Help us understand and reproduce the issue

In return, we commit to:

• Acknowledge your responsible disclosure
• Keep you informed of our progress
• Give you credit for the discovery (unless you prefer anonymity)
• Work diligently to fix confirmed vulnerabilities

Even as a hobby project, meniOS implements several security-conscious development practices:

• Static Analysis: Regular code review for common vulnerability patterns
• Unit Testing: Unity-based testing framework for critical components
• Coding Standards: Strict adherence to CODING.md guidelines
• Memory Management: Careful memory allocation and deallocation practices

• User/Kernel Separation: Implementation of Ring 0/Ring 3 privilege levels
• Memory Protection: Virtual memory management with proper page permissions
• Syscall Validation: Parameter validation in syscall interface
• Stack Protection: Careful stack management in kernel code

• Compiler Warnings: Build with strict warning levels
• Debug Symbols: Separate debug builds from release builds
• Reproducible Builds: Docker-based build environment for consistency

As development progresses toward userland support:

• Enhanced syscall parameter validation
• Improved memory permission enforcement
• Better error handling and bounds checking
• Stack canaries and guard pages

• ELF loader security validation
• Filesystem access controls
• Resource limiting and quotas
• Improved privilege separation

• Hardware security feature utilization (SMEP, SMAP, etc.)
• Control flow integrity
• Address space layout randomization (ASLR)
• Kernel stack protection

Contributors and security researchers can help by:

# Example tools that can be used
clang-static-analyzer src/
cppcheck --enable=all src/

# Build with debugging and sanitizers
make clean
make CFLAGS="-fsanitize=address -g" build

# Test in QEMU with memory debugging
make run QEMU_OPTS="-s -S"

• Syscall parameter fuzzing
• Keyboard input fuzzing
• Memory allocation/deallocation patterns
• Boot parameter fuzzing

High-priority areas for security review:

1. Memory Management (src/kernel/memory/)

   • Physical and virtual memory allocation
   • Page table management
   • Kernel heap implementation

2. System Calls (src/kernel/syscall/)

   • Parameter validation
   • Privilege checking
   • Return value handling

3. Process Management (src/kernel/process/)

   • Thread creation and termination
   • Context switching
   • Scheduler implementation

4. Hardware Drivers (src/drivers/)

   • Input validation
   • Hardware interaction safety
   • Interrupt handling

Since meniOS is an educational project, we encourage learning about OS security:

• "The Design and Implementation of the FreeBSD Operating System" (McKusick & Neville-Neil)
• "Operating Systems: Three Easy Pieces" (Arpaci-Dusseau)
• "Secure Coding in C and C++" (Seacord)

• Kernel exploitation techniques
• Memory safety in systems programming
• Privilege escalation vectors
• Hardware security features

• Static analysis tools (Clang Static Analyzer, Coverity)
• Dynamic analysis (AddressSanitizer, Valgrind)
• Fuzzing frameworks (AFL, LibFuzzer)
• Debugging techniques (GDB, QEMU debugging)

We appreciate all security researchers and contributors who help make meniOS more secure through responsible disclosure and security-conscious development practices.

This section will be updated as security issues are reported and fixed.

For security-related questions or concerns:

• Maintainer: Plínio Balduino
• Email: pbalduino [at] gmail [dot] com
• GitHub: @pbalduino

For general project questions, please use the GitHub Issues tracker.

Note: While meniOS is a hobby project, we take security seriously as part of the learning process and responsible development practices. Your contributions to improving the security posture of meniOS are greatly appreciated!