veilor-org/veilor-os
1
0
Fork 0
Code Issues Pull requests 2 Projects Releases 1 Packages Wiki Activity Actions

fix(overlay): preload uas so UAS enclosures bind post-modules-lock #13

Open
s8n wants to merge 1 commit from fix/preload-uas-module into main
pull from: fix/preload-uas-module
merge into: veilor-org:main
Conversation 0 Commits 1 Files changed 2 +71
s8n commented 2026-05-13 15:04:23 +01:00
Owner
Copy link

Problem

veilor-modules-lock.service sets kernel.modules_disabled=1 ~30s after graphical.target. uas is not built into the kernel image and only loads on demand when a UAS-capable USB-SATA bridge appears at boot. If no such device is present at boot, uas never loads, the lock engages, and any later hot-plug of an ASMedia / JMicron / Realtek UAS bridge fails:

usb 7-1: Device is not authorized for usage
modprobe: ERROR: could not insert uas: Operation not permitted

The enclosures interface descriptor advertises both BBB (08:06:50) and UAS (08:06:62) alt-settings. Kernel prefers UAS, so usb-storage stands down expecting uas to claim. Result: device authorizes in USBGuard, no sd* node appears, drive unreachable.

Reproduced 2026-05-13 on onyx with SK Hynix SC311 1TB in an ASMT105x (174c:55aa) enclosure during a VeraCrypt recovery session.

Fix

Ship /etc/modules-load.d/veilor-storage.conf via the overlay, listing uas and usb-storage. systemd-modules-load.service runs at boot, before veilor-modules-lock, so both modules are resident for the entire session and can bind hot-plugged devices freely.

Files

  • overlay/etc/modules-load.d/veilor-storage.conf (new) — preload list with explanatory comment block
  • docs/HARDENING.md — new "Removable storage (UAS preload)" subsection under USB with verification + runtime quirks fallback for future bad enclosures

Test plan

  • Build ISO from this branch
  • Install in QEMU+OVMF; let install settle 60s post-boot
  • lsmod | grep -E ^uas|^usb_storage → both present
  • cat /proc/sys/kernel/modules_disabled → 1
  • Attach virtual UAS-capable disk; verify sd* enumerates without manual quirk
  • Bare metal: USB-SATA enclosure hot-plug after boot → binds first try

Out of scope (follow-up)

  • docs/HARDENING.md says USBGuard ships with "empty allowlist" but overlay/etc/usbguard/rules.conf actually carries a HID allow rule. Doc drift, separate PR.
  • usbguard generate-policy is documented as a manual first-boot step but not invoked by veilor-firstboot. Could be automated post-pw-set so new installs arent left with bare HID allowlist + everything else blocked.
## Problem `veilor-modules-lock.service` sets `kernel.modules_disabled=1` ~30s after `graphical.target`. `uas` is not built into the kernel image and only loads on demand when a UAS-capable USB-SATA bridge appears at boot. If no such device is present at boot, `uas` never loads, the lock engages, and any later hot-plug of an ASMedia / JMicron / Realtek UAS bridge fails: ``` usb 7-1: Device is not authorized for usage modprobe: ERROR: could not insert uas: Operation not permitted ``` The enclosures interface descriptor advertises both BBB (`08:06:50`) and UAS (`08:06:62`) alt-settings. Kernel prefers UAS, so `usb-storage` stands down expecting `uas` to claim. Result: device authorizes in USBGuard, no `sd*` node appears, drive unreachable. Reproduced 2026-05-13 on onyx with SK Hynix SC311 1TB in an ASMT105x (`174c:55aa`) enclosure during a VeraCrypt recovery session. ## Fix Ship `/etc/modules-load.d/veilor-storage.conf` via the overlay, listing `uas` and `usb-storage`. `systemd-modules-load.service` runs at boot, before `veilor-modules-lock`, so both modules are resident for the entire session and can bind hot-plugged devices freely. ### Files - `overlay/etc/modules-load.d/veilor-storage.conf` (new) — preload list with explanatory comment block - `docs/HARDENING.md` — new "Removable storage (UAS preload)" subsection under USB with verification + runtime quirks fallback for future bad enclosures ## Test plan - [ ] Build ISO from this branch - [ ] Install in QEMU+OVMF; let install settle 60s post-boot - [ ] `lsmod | grep -E ^uas|^usb_storage` → both present - [ ] `cat /proc/sys/kernel/modules_disabled` → `1` - [ ] Attach virtual UAS-capable disk; verify `sd*` enumerates without manual quirk - [ ] Bare metal: USB-SATA enclosure hot-plug after boot → binds first try ## Out of scope (follow-up) - `docs/HARDENING.md` says USBGuard ships with "empty allowlist" but `overlay/etc/usbguard/rules.conf` actually carries a HID allow rule. Doc drift, separate PR. - `usbguard generate-policy` is documented as a manual first-boot step but not invoked by `veilor-firstboot`. Could be automated post-pw-set so new installs arent left with bare HID allowlist + everything else blocked.
s8n added 1 commit 2026-05-13 15:04:23 +01:00
fix(overlay): preload uas + usb-storage so UAS enclosures bind post-modules-lock
Some checks failed
secret-scan / gitleaks (HEAD + history) (push) Has been cancelled
Details
secret-scan / detect-secrets (entropy + cross-tool) (push) Has been cancelled
Details
secret-scan / gitleaks (HEAD + history) (pull_request) Has been cancelled
Details
secret-scan / detect-secrets (entropy + cross-tool) (pull_request) Has been cancelled
Details
secret-scan / summary (push) Has been cancelled
Details
secret-scan / summary (pull_request) Has been cancelled
Details
4f91fbb8f0 
veilor-modules-lock sets kernel.modules_disabled=1 about 30s after
graphical.target. Without uas already loaded, hot-plugged USB-SATA
bridges (ASMedia / JMicron / Realtek) that advertise both BBB and
UAS alt-settings fail to bind — the kernel prefers uas, usb-storage
stands down, and modprobe uas is denied by the lock.

Add /etc/modules-load.d/veilor-storage.conf via the overlay so
systemd-modules-load.service preloads uas + usb-storage at boot,
before the lock engages. Document the rationale and a runtime
quirks workaround in docs/HARDENING.md.

Incident: 2026-05-13, onyx, SK Hynix SC311 in ASMT105x (174c:55aa).
Some checks failed
secret-scan / gitleaks (HEAD + history) (push) Has been cancelled
Details
secret-scan / detect-secrets (entropy + cross-tool) (push) Has been cancelled
Details
secret-scan / gitleaks (HEAD + history) (pull_request) Has been cancelled
Details
secret-scan / detect-secrets (entropy + cross-tool) (pull_request) Has been cancelled
Details
secret-scan / summary (push) Has been cancelled
Details
secret-scan / summary (pull_request) Has been cancelled
Details
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin fix/preload-uas-module:fix/preload-uas-module
git checkout fix/preload-uas-module

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git checkout main
git merge --no-ff fix/preload-uas-module
git checkout fix/preload-uas-module
git rebase main
git checkout main
git merge --ff-only fix/preload-uas-module
git checkout fix/preload-uas-module
git rebase main
git checkout main
git merge --no-ff fix/preload-uas-module
git checkout main
git merge --squash fix/preload-uas-module
git checkout main
git merge --ff-only fix/preload-uas-module
git checkout main
git merge fix/preload-uas-module
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: veilor-org/veilor-os#13
No description provided.
Delete branch "fix/preload-uas-module"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?