Linux Kernel Hardening & Yocto meta-security

About the Course

Embedded system security doesn’t end with Secure Boot. What’s the point of a signed bootloader if the kernel is configured for debugging, not defense? This training fills the gap between “booted securely” and “runs securely”.

We focus on Linux kernel hardening, Secure Software Development Lifecycle (SSDLC), and Mandatory Access Control using AppArmor — all in the context of the STM32MP1 platform and the Yocto/OpenSTLinux ecosystem.

What we DON’T cover: Secure Boot (TF-A), file system encryption (dm-crypt/LUKS) — these are topics of separate trainings.

🎯 Project Goal: “Hardened STM32MP1 Image”

During the course, we don’t configure options in a vacuum. We build a hardened production image. Participants will create a system that:

✓ Passed CVE audit — all known vulnerabilities are patched or documented (VEX)

✓ Has binaries compiled with full protective flags — Stack Protector, FORTIFY_SOURCE, RELRO, PIE

✓ Blocks kernel memory access — CONFIG_STRICT_DEVMEM, dmesg restrictions

✓ Detects exploitation attempts — verification via LKDTM (Kernel Dump Test Module)

✓ Restricts application privileges — AppArmor in enforce mode

✓ Is monitored — auditd + AIDE for change detection

📅 Training Program

DAY 1: The Supply Chain – Secure Software Supply Chain

Vulnerability management and toolchain hardening. Before you harden the kernel, make sure userspace is secure.

Module 1.1: Vulnerability Management in Product Lifecycle

• The cve-check mechanism in Yocto: Mapping packages to the NVD database
• False positives problem: Backporting patches without version changes
• VEX (Vulnerability Exploitability Exchange) and CVE_STATUS variables
• Lab: Generating a CVE report for st-image-core, analyzing results, marking exceptions

Module 1.2: Toolchain Hardening — Secure Compilation

• GCC security flags: stack protector, FORTIFY_SOURCE, RELRO, PIE
• Toolchain configuration in Yocto — default settings and their modification
• Lab: Comparing compilation with different hardening levels

DAY 2: The Kernel – Kernel Hardening

The technical heart of the training. Default kernel configurations prioritize compatibility over security.

Module 2.1: Attack Surface Minimization

• Blocking RAM access through /dev/mem
• Hiding kernel addresses from userspace
• Debugging interfaces (DebugFS) in production — what to disable?
• Lab: Modifying kernel configuration and verifying changes

Module 2.2: KASLR on ARM 32-bit — Limitations and Workarounds

• Kernel Address Space Layout Randomization on 32-bit platforms
• Bootloader integration: kaslr-seed in Device Tree
• Discussion: Cost-benefit analysis of KASLR on Cortex-A7

Module 2.3: Self-Protection — Kernel Memory Protection

• Boundary verification with copy_from_user/copy_to_user
• Protection against kernel heap overflow
• Lab: Testing protection mechanisms with LKDTM

Module 2.4: Day 2 Summary

• Analysis of LKDTM test results
• Hardening impact on Cortex-A7 performance: Measurable but acceptable (<1-2% CPU)
• Q&A

DAY 3: The Lockdown – Mandatory Access Control and Auditing

Runtime protection layer. We assume the attacker will find a vulnerability — we limit the damage.

Module 3.1: AppArmor in Yocto and on STM32MP1

• Why AppArmor, not SELinux? Simplicity, performance, file paths
• AppArmor integration in Yocto: layers, kernel configuration, bootargs
• Common issues: BusyBox conflict with AppArmor tools
• Lab: Starting and verifying AppArmor on the target platform

Module 3.2: Application Profiling

• aa-genprof and aa-logprof tools — automatic rule generation
• Challenges on embedded: Limited RAM resources on STM32MP1
• Hybrid approach: “complain” mode on device, log analysis on host
• Lab: Restricting a web server (lighttpd)
  • Learning mode → profile generation → enforce mode
  • Verifying blocking of unauthorized access to /etc/passwd

Module 3.3: Auditing and Monitoring

• auditd — Tracking system calls (execve, open, connect)
• Log integration: Where do AppArmor logs go? (syslog vs auditd)
• AIDE (Advanced Intrusion Detection Environment) — Offline file change detection
• Lab: AIDE database initialization, binary modification, change detection

Module 3.4: Final Workshop

• Integration of all elements into a hardened image
• Deliverable: Yocto layer with hardening recipes to transfer to your own projects
• Q&A and consultation

💰 Pricing and Participation Models

I offer a flexible model tailored to the team’s skill level.

Option A: CORE (2 Days)

Ideal for teams that want to learn toolchain and kernel hardening but don’t need advanced MAC knowledge.

Option B: FULL HARDENING (3 Days) ⭐ Recommended

Complete training with AppArmor and monitoring. Essential for products requiring security certification or compliance.

Promotion: By choosing the 3-day package upfront, you save €100 compared to adding the 3rd day separately.

Small teams: For teams smaller than 5 people - rates are negotiated individually.

🏆 Why is it worth it?

🛠️ Requirements

Hardware (provided):

• STM32MP157C-DK2 board
• 16GB microSD card
• USB Type-C cable

Software:

• Ubuntu 20.04/22.04 LTS
• OpenSTLinux SDK (Kirkstone/Scarthgap)
• Pre-compiled sstate-cache (reduced build time)

Participant knowledge:

• Yocto basics (building images, adding layers)
• Linux basics (shell work, kernel configuration)

🎁 Hardware stays with participants after the workshop!

Want to reserve a date for your team? Contact me to arrange details. Harden your systems before someone finds a vulnerability in them.