The enlightened INT13 HDD path (enlightened_hdd_command) currently accepts any IdeCommand value from the guest-provided EnlightenedInt13Command.command field without validation.
Two questions worth investigating:
-
What commands does the Hyper-V synthetic BIOS actually send via the enlightened INT13 port? This requires access to the BIOS firmware source to determine the exact command set.
-
Should we restrict the enlightened path to only accept commands the BIOS is known to issue? Adding an allowlist would make the contract explicit and prevent silent misbehavior for unexpected commands — a defense-in-depth improvement.
Context: This came up during review of #3062 (adding WRITE_DMA_FUA_EXT to the 48-bit LBA setup). The fix in #3062 is a consistency fix between the enlightened register setup and handle_command(), but the broader question of which commands the BIOS actually sends — and whether we should enforce that — is worth tracking separately.
Related:
The enlightened INT13 HDD path (
enlightened_hdd_command) currently accepts anyIdeCommandvalue from the guest-providedEnlightenedInt13Command.commandfield without validation.Two questions worth investigating:
What commands does the Hyper-V synthetic BIOS actually send via the enlightened INT13 port? This requires access to the BIOS firmware source to determine the exact command set.
Should we restrict the enlightened path to only accept commands the BIOS is known to issue? Adding an allowlist would make the contract explicit and prevent silent misbehavior for unexpected commands — a defense-in-depth improvement.
Context: This came up during review of #3062 (adding
WRITE_DMA_FUA_EXTto the 48-bit LBA setup). The fix in #3062 is a consistency fix between the enlightened register setup andhandle_command(), but the broader question of which commands the BIOS actually sends — and whether we should enforce that — is worth tracking separately.Related: