Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

nvx-rs: check a GPT disk's kernel partitions in the guest

Open
#770 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
linux, rust
Domain
backend, testing

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 needs CAP_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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/nvx

All issues in microsoft/nvx

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.