Hi,

Disclosure: this report was drafted with AI assistance, then reviewed against
every source it cites (upstream edk2, Debian's packaging, OpenBSD's loader, and
the shipped firmware image). I understand it and can defend any part of it. The
patch below has been checked with `patch -p1 --dry-run` against debian/rules as
of 2026.05-2. Happy to make it shorter if you would rather have the gist.

`qemu-efi-riscv64` cannot boot OpenBSD/riscv64, and the escape hatch Debian
already ships for x86 and arm64 is not reachable on riscv64. The fix is one
line in debian/rules.

Summary
-------

The RISC-V platform applies the DXE NX memory protection policy, which makes
`EfiLoaderData` non-executable. OpenBSD's loader allocates the kernel buffer as
`EfiLoaderData` and jumps to it, so the kernel faults on its first instruction.

`debian/rules` already defines the escape hatch,

    NO_STRICTNX_COMMON_FLAGS = --pcd PcdUninstallMemAttrProtocol=TRUE

applies it to x86 and arm64, and ships a *strict* counterpart for each so the
relaxed build is the default and strict NX is opt-in:

    OVMF_4M_SECBOOT_FLAGS           = $(OVMF_4M_COMMON_FLAGS) $(NO_STRICTNX_COMMON_FLAGS) -D...
    OVMF_4M_SECBOOT_STRICTNX_FLAGS  = $(OVMF_4M_COMMON_FLAGS)                      -D...
    AAVMF_SECBOOT_FLAGS             = $(AAVMF_COMMON_FLAGS)   $(NO_STRICTNX_COMMON_FLAGS) -D...
    AAVMF_SECBOOT_STRICTNX_FLAGS    = $(AAVMF_COMMON_FLAGS)                        -D...

The two lines in each pair differ only by `$(NO_STRICTNX_COMMON_FLAGS)`, and
`install-qemu-efi-aarch64` builds and installs all three of its variants. RISC-V
has a single build with no opt-out and no variant:

    RISCV64_FLAGS     = $(COMMON_FLAGS)
    LOONGARCH64_FLAGS = $(COMMON_FLAGS)

So both other architectures already default to a relaxed image; riscv64 has no
such image at all. This is a request for parity, not a claim that the NX policy
or the value `0x7FD5` is wrong.

Patch
-----

diff -u against debian/rules as of 2026.05-2; applies with `patch -p1`: