OVMF LTO disabled and compiler warnings suppressed for reproducibility

[pbeza]

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.

[kvinwang]

Thanks for the report. We looked into this — these flags are inherited from the upstream openembedded-core OVMF recipe and are deliberate decisions by the Yocto maintainers.

The three flags form a causal chain:

1. -fno-lto: Added by Richard Purdie (Yocto maintainer) in commit 627b6ed763 to ensure build reproducibility — LTO produces non-deterministic output. EDK2 upstream also provides GCCNOLTO as an officially supported toolchain alternative.

2. -Wno-stringop-overflow: When LTO is disabled, GCC 12+ emits false-positive -Wstringop-overflow warnings on EDK2 code. Since EDK2 builds with -Werror, these become fatal. This was addressed by Khem Raj in commit 7b67f19d35; Fedora's edk2 package carries a similar patch.

3. -Wno-maybe-uninitialized: Same situation — without LTO, GCC lacks cross-TU information and produces false-positive warnings. This is a known recurring issue in EDK2 ([Build fail on Ubuntu 20.04.2][OvmfPkg] SecTdxHelper.c:751:26: error: ‘PhysicalEnd’ may be used uninitialized in this function [-Werror=maybe-uninitialized] tianocore/edk2#10840, "maybe-uninitialized" warnings emitted by gcc-5.5.0 (Bugzilla Bug 3228) tianocore/edk2#8765).

In short, LTO is disabled for reproducibility, and the warning suppressions are a necessary consequence of that — they address GCC false positives, not real bugs being silenced.

[kvinwang]

We also tested removing the warning suppression flags to see what actually triggers. With -Wno-stringop-overflow and -Wno-maybe-uninitialized removed, the build produces exactly 1 warning (turned into an error by EDK2's -Werror):

SecTdxHelper.c:750:26: error: 'PhysicalEnd' may be used uninitialized [-Werror=maybe-uninitialized]

Looking at the code, this is a false positive — PhysicalEnd is assigned in both branches of an if/else:

if (CpusNum > 1) {
    Status = AcceptMemoryForAPsStack(VmmHobList, APS_STACK_SIZE(CpusNum), &PhysicalEnd);
    ...
} else {
    PhysicalEnd = 0;
    ...
}

GCC without LTO can't prove the pointer write in AcceptMemoryForAPsStack always succeeds, so it flags it. No -Wstringop-overflow warnings were observed at all.

Given that the only suppressed warning is a confirmed false positive in upstream EDK2 code we don't maintain, we'll keep the current flags as-is.