mount: probe VBR for GPT entries with unrecognized type GUIDs#32
mount: probe VBR for GPT entries with unrecognized type GUIDs#32crux161 wants to merge 1 commit into
Conversation
DarkMatterCore
added
enhancement
Only Microsoft Basic Data and Linux Filesystem Data GPT partition entries are currently inspected, so standard filesystems placed behind other type GUIDs are skipped. For example, the Windows Recovery Environment partition created by Windows Setup uses type GUID DE94BBA4-06D1-4D40-A16A-BFD50179D6AC yet holds an NTFS volume. Probe the VBR (and, on GPL builds, the EXT superblock) for any entry whose type GUID is non-empty and was not handled by the dedicated branches. A GPT entry's LBA span is also validated against the logical unit's block_count at the top of the function, before any branch issues a read. This guards every branch against uninitialized/garbage partition array entries (e.g. a type GUID 0xF4-filled with lba_start == 0xF4F4F4F4F4F4F4F4) whose reads would target out-of-range LBAs and can stall flaky USB drives, force a BOT mass-storage reset and drop them off the bus. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
crux161
force-pushed
the
feature/gpt-unrecognized-vbr-probe
branch
from
2a55b2f to
d1d1a02
Compare
|
Thanks for the review! Addressed all four points in the latest push:
One small note on the bounds check: I deliberately left out an explicit Compiles cleanly for |
|
As a side note, two additional comments:
|
Match the revised DarkMatterCore/libusbhsfs#32 after maintainer review: move the LBA bounds check to the top of the entry parser (guarding every branch), probe the EXT superblock as well as the VBR for unrecognized type GUIDs, and reference the Windows Recovery Environment partition as a concrete example of a standard filesystem behind a non-standard GUID. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| /* Discard entries whose LBA span falls outside this logical unit before any branch below | ||
| * issues a read. This filters out uninitialized/garbage partition array entries (e.g. a | ||
| * type GUID 0xF4-filled with lba_start == 0xF4F4F4F4F4F4F4F4) whose reads would target | ||
| * absurd LBAs, which can stall flaky USB drives, force a BOT reset and knock them off the bus. */ | ||
| if (entry_lba >= lun_ctx->block_count || gpt_entry->lba_end >= lun_ctx->block_count || gpt_entry->lba_end < entry_lba) |
There was a problem hiding this comment.
Please make this comment block follow the same format as other multi-line comment blocks in this codebase by making each line sart with /* and end with */.
| /* Some tools place standard exFAT/FAT/NTFS (or even EXT) volumes behind GPT type | ||
| * GUIDs other than the Microsoft Basic Data / Linux Filesystem Data ones handled | ||
| * above. For instance, the Windows Recovery Environment partition created by Windows | ||
| * Setup uses type GUID DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, yet holds an NTFS volume. | ||
| * Probe the VBR (and, on GPL builds, the EXT superblock) before skipping the entry. */ |
There was a problem hiding this comment.
Please make this comment block follow the same format as other multi-line comment blocks in this codebase by making each line sart with /* and end with */.
There was a problem hiding this comment.
On a second thought, the comment itself is misleading, since it doesn't really reference the fact that we're intentionally looking for an empty GUID here.
| /* Some tools place standard exFAT/FAT/NTFS (or even EXT) volumes behind GPT type | ||
| * GUIDs other than the Microsoft Basic Data / Linux Filesystem Data ones handled | ||
| * above. For instance, the Windows Recovery Environment partition created by Windows | ||
| * Setup uses type GUID DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, yet holds an NTFS volume. | ||
| * Probe the VBR (and, on GPL builds, the EXT superblock) before skipping the entry. */ |
There was a problem hiding this comment.
On a second thought, the comment itself is misleading, since it doesn't really reference the fact that we're intentionally looking for an empty GUID here.
|
Superseded by #33. Closing this PR. |
2 participants
Summary
usbHsFsMountParseGuidPartitionTableEntry()currently inspects only Microsoft Basic Data and Linux Filesystem Data GPT entries. Some tools place otherwise standard exFAT/FAT/NTFS volumes behind non-standard partition type GUIDs, so those volumes are silently skipped and never mounted.This adds a fall-through branch that probes the volume boot record for any entry whose type GUID is non-empty and wasn't handled by the dedicated branches — with an LBA bounds check first, which turned out to be essential.
Why the bounds check matters
Some USB drives leave uninitialized/garbage entries in the GPT partition array (observed in the wild: a type GUID that is
0xF4-filled, withlba_start == 0xF4F4F4F4F4F4F4F4). Probing such an entry without validation issues a read at an out-of-range LBA, which on flaky BOT drives produces anInvalid CSW, forces a mass-storage reset, and can knock the drive off the bus entirely — after a real volume on the same drive had already been registered.So before probing, the entry's range is validated against
lun_ctx->block_count:Genuine non-Microsoft-GUID volumes are still detected; garbage entries are skipped without touching the device.
Testing
Built
BUILD_TYPE=gplfor Switch (devkitA64) and exercised with the debug build (-lusbhsfsd,sd:/libusbhsfs.log) on real hardware (firmware 21.1.0 / Atmosphère 1.11.1):0xF4F4…entry →Invalid CSW→ BOT reset → drive removed.Discovered while adding exFAT-on-GPT support to SwitchWave (averne/SwitchWave#19), which had been carrying this as a local patch; upstreaming so it can be dropped there.
🤖 Generated with Claude Code