Repository navigation
Conversation
uefisettings failed to build for 32-bit targets such as i686 (E0308 at both ioctl calls, #4). nix's ioctl_read! and ioctl_write_ptr! take a pointer to the type that sizes the request, c_long here, and chattr passed an i64, which is c_long only where long has 64 bits. The kernel itself reads and writes an unsigned int (ioctl_getflags() and ioctl_setflags() in fs/file_attr.c, Linux v6.17); only the request numbers, _IOR('f', 1, long) and _IOW('f', 2, long), encode the size of a long. The ioctls now take the request number built for a long, as before, with an unsigned int buffer, and the flags are c_uint throughout, so nothing converts or truncates them. The request numbers do not change. clippy-i686 lints i686-unknown-linux-gnu, so a 32-bit build error fails make lint. This supersedes the unmerged fix on the bugfix/issue4 branch (36a405b), which keeps a c_long buffer, converts it with as and makes the flags i32: the kernel reads and writes the first 4 bytes of the 8-byte long, which on big-endian 64-bit targets are its high half, not the flags, and as hides truncation. Signed-off-by: Dmitrii Okunev <xaionaro@meta.com>
On i686-unknown-linux-gnu, off_t has 32 bits, so the mmap fallback of
extract-db rejected every page from 2 GiB on ("does not fit off_t"),
and read_mapped_reads_above_4gib failed there; no check ran the tests
for a 32-bit target. copy_mapped_page now maps through mmap64() with
an off64_t offset, which the libc crate provides on glibc and musl.
The new check test-i686 runs the tests for i686-unknown-linux-gnu on
the host, which needs gcc's 32-bit libraries; CI's lint-and-test job
installs gcc-multilib and runs it next to test.
Signed-off-by: Dmitrii Okunev <xaionaro@meta.com>
test_clear_attrs compared the flags after set_attrs with the initial ones, so it never checked what clear_attrs left, and a new file on tmpfs or btrfs has no other flag that clear_attrs could drop. With FS_NODUMP_FL set, it now clears FS_IMMUTABLE_FL, which no new file has or inherits, so that clearing it needs no capability, and checks that FS_NODUMP_FL stays; its last check reads the flags after clear_attrs. FS_NODUMP_FL is the kept flag as it is the only one that an owner may set on both ZFS and tmpfs: OpenZFS takes only immutable, append-only, nodump and projinherit, tmpfs no projinherit, and immutable and append-only need CAP_LINUX_IMMUTABLE. So the set_attrs and set_all_attrs tests cannot catch a call that drops the other flags, which takes a second flag on the file. Signed-off-by: Dmitrii Okunev <xaionaro@meta.com>
…iomem The guest tests read the published HII database with read() of /dev/mem, which fails with EFAULT on arm64, whose Linux maps neither runtime services data nor reserved memory, and on 32-bit x86 above the end of Linux's low memory (Linux 6.17: valid_phys_addr_range() in arch/arm64/mm/mmap.c and arch/x86/mm/mmap.c). uefisettings then falls back to mmap(), which the guest crate, free of unsafe code, cannot do. So on those architectures the extract-db test would fail, and on 32-bit x86 also the premise of hii_devmem_guard, which expects EPERM. publish-hiidb now also puts the CRC-32 of the database, from the firmware's CalculateCrc32, in the volatile HiiDBCrc32 variable, and the extract-db test compares the length and CRC-32 of the extracted file with the published ones. The premise of hii_devmem_guard becomes that the database is in a System RAM range of /proc/iomem, which /dev/mem refuses under STRICT_DEVMEM. Signed-off-by: Dmitrii Okunev <xaionaro@meta.com>
The guest's OVMF and busybox came from the host's apt, so an upgrade of ovmf or busybox-static on the runner changed the guest with no change here. apt cannot supply them for guests of other architectures either: busybox-static of two architectures does not co-install, as it has no Multi-Arch field, and Ubuntu 26.04 has no ovmf-ia32. guest-packages-x86_64 now pins the kernel, OVMF and busybox by sha256, as kernel.sha256 pinned the kernel, and fetch-packages.sh, which replaces fetch-kernel.sh, downloads and unpacks .rpm and .deb packages alike. It checks the whole list before any download, takes only HTTPS URLs and redirects, and creates ROOT only once every package is unpacked. Each package lists its mirrors with a permanent archive last, and a mirror that fails or serves other bytes is skipped. Signed-off-by: Dmitrii Okunev <xaionaro@meta.com>
run.sh read scenarios.tsv with `while read`, which fails on a last line that lacks a newline, so the loop ended before that line: its scenario never booted and run.sh still passed, even when the command line named that scenario. The awk checks before the loop read the line, so nothing reported it. The loop over the built executables had the same shape; jq ends every line it prints, but run.sh no longer relies on that. Both loops now also take a last line without a newline, as fetch-packages.sh does. The other reads in tests/qemu and scripts take here-strings, which end with a newline, use mapfile, which keeps such a line, or read a single line from /proc or a shebang. Signed-off-by: Dmitrii Okunev <xaionaro@meta.com>
edk2-stable202508's BaseTools fail to build with gcc 15 and glibc 2.43, as on Ubuntu 26.04: for C23, the default of gcc 15, glibc's strstr() returns a const pointer for a const argument, and EfiRom.c:78 assigns it to a CHAR8 *, which -Werror=discarded-qualifiers rejects. EDK2 fixed that in 9af06ef3, first released in edk2-stable202602. The newest release, edk2-stable202608, builds DriverSample on Ubuntu 24.04 and 26.04. Of DriverSample, only 0d26d944 changes what the tests read: it drops `default = TRUE` from the check box whose CHECKBOX_DEFAULT flag keeps it checked, so the HII database is 6 bytes shorter, and every tested question and default stays. Cherry-picking 9af06ef3 onto edk2-stable202508 would make the script fetch and apply a commit, and the pin would stop being a release tag. EDK2 publishes no DriverSample.efi, and committing one would replace the pinned source with a binary that cannot be audited. Signed-off-by: Dmitrii Okunev <xaionaro@meta.com>
The QEMU tests booted only x86_64 guests. run.sh now takes the architecture, x86_64, i686 or aarch64, and finds its QEMU, firmware, kernel, modules, terminals and EDK2 architecture in one table; make test-e2e-qemu runs all three. i686 is 32-bit throughout, with Debian 12's 686-pae kernel, OVMF IA32 and an IA32 DriverSample, so uefisettings meets 32-bit firmware and a 32-bit kernel's /dev/mem. aarch64 runs under TCG on the same x86_64 host, with AAVMF, Fedora's aarch64 kernel and a virtio console as the test terminal, which the new kernel parameter uefisettings.tty= names. init loads the kernel modules that run.sh copies, efivarfs on i686. run.sh drops the QEMU and DRIVER_SAMPLE_DIR variables: one value cannot serve three architectures, and PATH chooses the QEMU. Next to the cross gcc of ubuntu-packages, which conflicts with gcc-multilib, test-i686 takes libc6-dev-i386 and lib32gcc-<gcc version>-dev, as README.md now says. Each boot also leaves bootN.qemu.log, how QEMU saw the guest end: a poweroff makes a shutdown request, a reset none, and each CPU's last KVM exit is 8 after a triple fault; run.sh prints it for a failed boot. CI runs both jobs on ubuntu-26.04. The QEMU job needs it: QEMU 9.0 and newer fault unaligned loads from Device memory as arm64 does, so only there can the aarch64 guests catch a regression of #12; Ubuntu 24.04 has QEMU 8.2. The lint job moves with it, for one image and one migration. As gcc's default CPU varies, build-driver-sample.sh builds the X64 DriverSample for the baseline one, x86-64: the runners' gcc, Ubuntu's amd64v3 build, defaults to x86-64-v3, whose AVX instructions fault in the firmware, which runs with CR4.OSXSAVE clear. publish-hiidb puts the database one byte into its pages, so uefisettings reads the first page from an unaligned address on every architecture. Two tests check that the guests keep exercising what they should: read() of /dev/mem serves the database only on x86_64, so on i686 and aarch64 the extract test passes only through the mmap() fallback of uefisettings; and on aarch64 a 64-bit load from the unaligned address dies of SIGBUS, which QEMU before 9.0 does not raise. Signed-off-by: Dmitrii Okunev <xaionaro@meta.com>
xaionaro
force-pushed
the
qemu-multiarch
branch
from
October 18, 2026 18:53
5174280 to
b9603e6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.