linuxboot / linuxboot/heads

Call for consultation services communtiy can offer

Open
#2,194 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Makefile
Stars
1.6k
Forks
211
Avg merge
4d 21h
Merged PRs (30d)
6

Description

https://osresearch.net/Consultation-Services/ was written in 2024 per merged https://github.com/linuxboot/heads-wiki/pull/164 but i'm the only one there and nobody proposed a PR to offer other consultation services. CC @root-hardenedvault?

I welcome modifications there, after of course reviewing who those added people would be.

Alternative to
- https://github.com/linuxboot/heads/issues/2166
- https://github.com/linuxboot/heads/issues/2027

I am no king nor dictator here. If I cannot get funded properly, I need to be made redundant. Let's make this happen.
Also related

[2024 - QubesOS mini-summit - Jan Suhr & Thierry Laurion - Future of Measured Boot such as Heads (Design Session)
Abstract](https://youtu.be/ZPeidhgNBtg?list=PLuISieMwVBpL5S7kPUHKenoFj_YJ8Y0_d) Which was a plan to make Heads obsolete. 2 years later, it's not the case. Let's work torward that goal?

Conference AI summary:
> Jan Suhr (Nitrokey) leads a design discussion on Heads' measured-boot architecture: a coreboot + Linux-payload firmware using a USB security dongle as root of trust to mitigate evil-maid attacks, paired with Qubes OS on Nitropads. The central UX pain point: users must re-sign after every kernel update because Heads verifies exact hashes of /boot files. "If you compare it to ordinary PC users, this is in fact complicated — this is a burden," Suhr states, noting this blocks mainstream adoption. Alternative architectures debated: UKI (Unified Kernel Image) could solve the resigning problem by reducing changed files from five to one and enabling signature-based rather than hash-based verification. Porting Heads' logic to UEFI/TPM was discussed, but would require reimplementing all the bash-based measurement logic — "if funding is unlimited, everything's possible," Laurion quips. DRTM was considered but dismissed as server-only and requiring PCI-device reset. OpenPGP card support in UEFI was explored but deemed "quite expensive" (requiring Rust reimplementation). The group converged that making attested boot mainstream requires: kernel updates without manual resigning, richer user feedback on what changed in grub configuration, OS-side signing integration, and potentially UKI adoption.

CC @jans23: maybe its time to make a joint public talk to push your plan forward?

Contributor guide

Open the contributing guide

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.

Research direction

Start by reading the existing Consultation Services page at osresearch.net/Consultation-Services/ and the linked alternative issues; the payload names no repository file, test, or implementation entry point. Done would require a reviewed PR adding agreed, vetted consultation services and people to the page.

Written by the indexing model from the issue text.

Assessment

Domain
content, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.