OVMF LTO disabled and compiler warnings suppressed for reproducibility #48

The OVMF build configuration in meta-dstack/recipes-core/ovmf/ disables Link-Time Optimization (LTO) and suppresses compiler warnings, reducing both the compiler's ability to detect bugs and the resulting binary's optimization for security-relevant transformations.

Root Cause

The OVMF build recipe disables Link-Time Optimization (LTO) and suppresses several compiler warnings:

# dstack-ovmf_git.bb:125-128
EXTRA_OEMAKE += "EXTRA_OPTFLAGS='-fno-lto'"

# dstack-ovmf_git.bb:141
CFLAGS += "-Wno-stringop-overflow -Wno-maybe-uninitialized"

• -fno-lto: Disables LTO, which is done for build reproducibility (LTO can produce non-deterministic output). Without LTO, the compiler misses cross-module optimization opportunities including some security-relevant dead code elimination.

• -Wno-stringop-overflow: Suppresses warnings about string operations that may overflow buffers. These warnings often identify real buffer overflow bugs.

• -Wno-maybe-uninitialized: Suppresses warnings about potentially uninitialized variables. Uninitialized memory reads can leak sensitive data or cause undefined behavior.

Attack Path

1. A real buffer overflow exists in the OVMF firmware code
2. GCC would normally warn about it via -Wstringop-overflow
3. The warning is suppressed by -Wno-stringop-overflow
4. The bug goes undetected during the build
5. The resulting firmware contains an exploitable vulnerability
6. Firmware runs in the CVM's highest privilege level (SEC/PEI phase)

Impact

Compiler warnings that could identify security-critical bugs (buffer overflows, uninitialized memory) are suppressed. The firmware runs at the highest privilege level inside the CVM and is the first code to execute. Bugs in OVMF firmware could compromise the entire CVM before the OS even boots.

Suggested Fix

1. Fix the underlying code issues that trigger the warnings rather than suppressing them
2. If suppression is truly necessary for reproducibility, audit the specific code locations that trigger warnings and document why they are safe
3. Consider using -Werror with targeted suppressions per-file rather than global suppression
4. For LTO: investigate deterministic LTO options (-flto=auto with fixed thread count) or accept the reproducibility trade-off for security

Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.