nvx-rs: check a GPT disk's kernel partitions in the guest
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start with parent issue #621 and the guest GPT path in nvx::guest::gpt::read_disk; review reference implementation PR #715 on its branch for the proposed behavior. The work covers sysfs partition checks, conditional BLKRRPART rereads with deadline handling, consistent reads, returned block devices, and privileged microVM scenarios. Done means those cases are covered and kernel partitions are validated against the GPT table.
Written by the indexing model from the issue text.
Description
Deferred to: platform clones (meta B, to be filed), whose restore substitutes the distro under a running kernel. From: #621 (A3.3), which closes without it. Reference implementation: #715, not merged, on branch esaurez/a3-gpt-device-validation-20261020.
#621 specified that, after a partition-table reread, each kernel partition match its validated entry before a deadline. The first iteration of A3.3's device code leaves that out. nvx::guest::gpt::read_disk reads a GPT disk's table through the block device that the guest's kernel attached, at the device's logical block size and size, and checks it, with the expected disk GUID, through nvx::gpt. The guest then uses the partitions that the kernel created when it found the disk, such as /dev/vda2, without comparing them with the table or asking the kernel to reread it. For a disk that the host stages read-only and attaches when it creates the VM, the kernel reads the same table before the guest's init starts, and nothing changes it afterwards.
This issue tracks the rest, for when a guest needs it: for example, for a disk whose table can change under a running kernel, or for a guest whose disks other programs manage.
- Compare the kernel's partitions of the disk, as sysfs describes them (number, start and size), with the table's, and refuse missing and extra partitions.
- Reread the table (
BLKRRPART) only when they differ, then wait, with a deadline and short pauses, until they match, and refuse them when the deadline passes. The reread needsCAP_SYS_ADMIN, and fails while a partition of the disk is open. - Take a consistent view: never combine partitions, or the attributes of one partition, read before and after a reread.
- Return the partitions' block devices: the first partition's and the layers'.
- Privileged tests as a microVM scenario, with a test-only guest program shared into the guest rather than a larger release initramfs: a crafted GPT disk; missing, extra, moved and late partitions; and an MBR that the kernel reads in place of the table.
#715 implemented all of this, and passed CI and its reviews. Built as optimized as the guest binaries, its validation of a read-only disk, as the kernel found it at boot, took 0.4 to 0.9 ms on WHP and MSHV; the reread that it skipped there took 0.6 to 1.4 ms.
- Dominant language
- Python
- Stars
- 408
- Forks
- 28
- Avg merge
- 16h 20m
- Merged PRs (30d)
- 355
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/nvx
-
Track nvx-rs host VMM supervisor bugs: a non-UTF-8 process name at a reused PID blocks reconcile, reattach, and stopPossibly taken @56steve claimed this 2 days ago. Openbug-hunt confirmed good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
microsoft/nvx#720 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 24/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
fossasia/visdom-dev#77 ·
Maintainers usually reply within 4 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
aws-cloudformation/cfn-lint#4890 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
volcengine/OpenViking#6521 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
AstrBotDevs/AstrBot#10720 ·
Maintainers usually reply within 1 day