⚠️Microsoft’s AI Starts Reading All Your WhatsApp, Signal Messages. Even if you don't use ai, if your recipient uses it, you're cooked.
Recall’s launch means it’s time for Signal and WhatsApp and others to end their linked device options or provide some way for messages to be tagged so as only to appear on primacy devices — meaning phones.
#news #security
Further to my other recent post, I've now updated the "next" branch of coreboot, in lbmk, and merged it with the "default" branch. Now all boards (except asus kgpe-d16, kcma-d8 and kfsn4-dre) are on the same updated coreboot revision, up to date, as of 20 April 2025. Patch:
https://browse.libreboot.org/lbmk.git/commit/?id=c7569a67145a9534b14f477e088bb60e4330f9be
@tlaurion And I give special thanks to the Heads project, which committed a build fix for other boards when merging T480 patches, which is required, that I ported from Heads:
I was sent a @novacustom laptop preinstalled with Qubes, Coreboot, and tons of other nifty privacy & security perks. Here's my full review where I break down the laptop, what I love, and what I don't love! Check it out: https://www.youtube.com/watch?v=NlEi0O8pPWo
V540tu Dasharo+Heads was released today!
https://docs.dasharo.com/variants/novacustom_v540tu/releases_heads/#v090-2025-03-20
> Thierry took our advice afterall and merged T480 in its current state for now
No.
> the logic in Heads's T480 integration is based on lbmk's implementation in Libreboot.
No.
> I got annoyed because he was making demands that @mkukri do work to merge the T480 patches upstream - which he plans to, but Thierry demanded it *now*. Disrespectfully.
No.
----
Facts as code/dependencies:
Coreboot base:
- Heads relies on coreboot 24.12 release commit as can be seen per https://github.com/linuxboot/heads/blob/6279500e5bee5461521964603ab8c5c38812fdf6/modules/coreboot#L101-L110
Coreboot patches:
- Heads took coreboot patchtrain https://review.coreboot.org/c/coreboot/+/83274
- Those patches, and additional hack can be seen under https://github.com/linuxboot/heads/tree/master/patches/coreboot-24.12
- Additional hack is under https://github.com/linuxboot/heads/blob/master/patches/coreboot-24.12/0004-do-not-break-building-other-thinkpads-with-the-hacks.patch
Facts correction:
> the logic in Heads's T480 integration is based on lbmk's implementation in Libreboot
Heads had to see what lbmk used for t480 board as hash of coreboot upstream fork to apply under review coreboot patchtrain https://review.coreboot.org/c/coreboot/+/83274/25.
Otherwise, heads/lbmk build systems do really similar and really different things. The logic in Head's t480 integration was not based on lbmk's implementation. Heads uses coreboot fork commit/release tarballs as can be seen under modules/coreboot and applies patches if any still needed exists (that weren't merged upstream yet, while needed per Heads). Then boards/*/*.config specify versions of coreboot/linux which varies across boards, while other modules/* are versioned bumped for all boards at the same time.
Agreed that Heads buildsystem is more complex, but that complexity becomes needed when reproducible builds of linux common tools are to be packed as a payload. Again, we cannot compare our buildsystems because they do not do the same things. This is counter productive in public post outside of requiring clarifications from another party on false claims, misleading viewers to believe things that are inadequate.
Sorry Leah, but if you thought Heads was using u-root instead of busybox+a lot of other standard unix tools it builds itself from source, this simply means you never built nor used Heads up to now. I would prefer if you didn't say Heads is X or does Y until you built/flashed Heads at least once on a test board with it, please, and refrain doing public claims, requiring me to clarify things publicly while personal walls. I do not enjoy feeling the need to clarify false claims that shouldn't have been made originally; I consider this wasted time, since those should happen under Heads community space.
This whole discussion started because you said publicly that Heads was using u-root, which is false. This is linuxboot as a project aimed mostly to servers, replacing UEFI DXE part for not so well documented boards, while u-root project is really active and aims at replacing busybox. Details.
And then, since liberachat is capricious for tor, irc<->matrix bridges are broken between our communities, so I continued here instead of in our own communities official channels. Heads community members reached out as well but were considered spam. And here we are, spending time clarifying things that shouldn't.
In the future, I will comment upstream on coreboot patchset and propose PR for docs changes I guess, otherwise scattering communications and loosing both our time. My learning on this is that only upstream and focused on outcome discussions matter.
My point, here again dismissed, I don't know why, is that there is "black magic" or a "voodoo dance" that is not needed in libreboot flashing documentation for t480 (and I expect the same for t480s).
Science/engineering requires to repro things. t480 board owners, and myself challenging libreboot instructions, concluded that it was not needed to do aforementioned steps (erase spi through flash tool, then flash zeroed file, then tb.bin which is the only step needed, really), point still dismissed in your previous answers: stating libreboot docs can be referred as is. They should be corrected, and then Heads could refer to libreboot docs.
By lack of possible collababoration with libreboot, with attempts (plural) by board owners to chat in libreboot channel, me here: Heads documentation for t480 removed unneeded steps, board owner hacked upstream patchset used under libreboot. And this is why I call for upstream collaboration in the future.
I repeat, in this case, upstream code reference is libreboot until coreboot merges code. Documentation is libreboot for now until there is effort upstreaming our docs under coreboot docs: https://doc.coreboot.org/
Heads effort on t480 will not extend to t480s because there is no board owner technical enough that showed leadership to redo what was done for t480 (40h of unpaid/properly compensated time on my side here), while future might be brighter with mentorship done here, while I do not have the board nor plan to have all coreboot supported boards: Heads is a community effort; Heads requires technical board owners to take port lead/co-maintainership to thrive and propel other boards ports. In that regard, Heads is a coreboot payload; a linux based bootloader replacement with its own features and agenda. I repeat once more; there needs to be proper seperation of duties and understanding of who does what. Heads is not coreboot/libreboot/skulls as those are coreboot distributions packing already supported payloads; Heads is that payload with its own buildsystem to arrive to that goal, with reproducible build approach where roms are built reproducibly from CI is a directly flashable form. Heads doesn't pretend to be a coreboot distribution in the large sense of things, but needs to build coreboot to have its payload stitched in it, alongside all other blobs needed to have fully externally flashable roms/internally upgradable roms. Therefore, Heads needs to collaborate upstream/downstream for all its dependencies/forks/OEMs/rebrandings and time is limited.
TLDR: my suggestion, not demand, is that libreboot reviews its documentation for t480 in regard of tb.bin flashing from downstream Heads effort, which corrected the facts with lots of duplicated effort, reviews, iterations to arrive to its merged state, including participation upstream where it was possible.
Correction of facts:
This is not something personal, caprice. Its politics. To better the ecosystem if the real goal is to make this easy for users to flash, code to review/better, use, and ease support without constantly reinventing the wheel, duplicating efforts, etc. Otherwise we won't fill what I still believe is our common vision: to have coreboot on a maximum number of platforms out there, while easing developers onboarding on our projects. We need to unite here, not be enemies picking stupid ego fights. We need to take time and reflect on what we do and how we do it, if, of course, the mission is aligned with vision.
Note that the https://osresearch.net/T480-maximized-flashing/ doesn't instruct users to
- Stay on UEFI, disable battery/adaptive usb from UEFI menu
- Use flashrom to erase spi content
- Flash a zeroed file
- Then flash tb.bin
Documentation was duplicated since it was not possible to discuss those matters so Heads could refer to libreboot docs. Again duplicating efforts.
Ideally (should, not must: but ideal), flashing docs should be under coreboot docs, not repeated into all downstream coreboot distribution. We don't do anything different here then
- Disassembling instructions for boards, CMOS battery position and battery wiring position.
- Point where SPI chips are, their form factor and clip/probe sizing and voltage range of all SKU for same board (newer platforms have SPI chips for same model ranging from 1.8v to 3.3v and should be considered in the future).
- Instruct to use a programmer of choice (not to be duplicated in each board instructions, referred to instead) to flash those chips.
Upstream should document those things for all coreboot boards supported, not us. Downstream projects should refer to that upstream doc.
I think we should collaborate in that goal. Otherwise its just too much duplicated work. Even boards in our downstream work duplicate parts of the same docs across boards.
This is in my opinion, a lack of time to do more important things. Note that I'm not using must, but should. I'm not doing demand, just speaking from my experience, sharing knowledge and trying to collaborate, not create drama.
You blocked me before I had a chance to explain myself nor the facts, also flagging my account for moderation. Facts are the only thing important to me: upstream collaboration is needed when it comes to a coreboot port. Not an attack, not a demand. Not an ego fight. A simple fact.
I restate, lbmk builds boards in bubbles independent of each other and is why t480, built in its bubble, worked without breaking other boards for 24.12 which lbmk t480/t480s boards are based on, and why it didn't break other thinkpads, nor other skylake+ boards.
I never made "demands" outside of the obvious need of working things upstream, not in bubbles/silo, so that time is spent fixing ecosystem to benefit the most, not just some. If you consider this "my demand", of course there is gonna be perceptional drama. I have/had no personal benefit nor personal gains whatsoever helping the t480 port but receive more collaboration for future ports, for which we are supposed to share same vision: bring coreboot to more people. I wanted technical board owners to be able to port other boards under Heads, not do them all myself. I repeat, that requires coreboot forks/upstream to not break other things. Also, since libreboot mission with its minimal blobs policy, if there is better collaboration between our projects, time to deliver ports could be reduced a lot in the future, since the work done by Heads for blobs can directly benefit libreboot and vice versa, as it happened in the past already, fulfilling our common mission.
Working upstream is not a demand. its simple logic. I didn't mean to be disrespectful. And won't engage in drama publicly like this in the future: it fragments the already fragile ecosystem we should all participate in, together, not against each other. Drama was blocking me, Leah and twisting my words. Saying Heads is something it's not, and saying publicly i'm pestering you or coreboot developers with personal demands, as if I was entitled to something. I'm not.
Comment upstream https://review.coreboot.org/c/coreboot/+/83274/25#message-eaf4e15058429a1f1944de74e1118c8275b2b532
No: Heads couldn't use upstream patch train as it is used under lbmk. This "hack" https://github.com/linuxboot/heads/commit/f76558601576409c2bb0fc49f0a119a97d8506fe was made by a non-coreboot dev (https://github.com/gaspar-ilom) to fix upstream build regressions on other Thinkpads (and possible still existing regressions on other Skylake+ based platforms if build outside of lbmk bubble) until things are fixed upstream.
Hoping for better systemic collaboration forward. And less drama. I have no time for drama. But I make time to fix what is needed, but I do not pretend I can do everything alone without everyone doing what they do best doing their thing, without ego fights.
"The ESP32 backdoor that wasn't"
@libreleah @mkukri I'm. Sorry if I hurted your feelings.
Videos are made on how to flash tb, following instructions that don't seem to be needed. Conferences were made stating that t480/t480s were supported but coreboot, which was false. Things need to be reproducible.
People came to Heads asking for port. Said I wouldn't do it but mentor to do the port if it was supported. 30h later, one technical board owner patched patchset so that it doesn't cause regression, but none are coreboot devs.
Therefore efforts are duplicated and a waste of time, because it's hacks on top of hacks.
I respect initial work of @mkukri and endeavors of libreboot /mini free goals of making coreboot more accessible. But this port got traction before being ready without causing regressions.
The rest of the world is rebasing their work on top of 24.12 and for that to happen, hacks need to be added on top of prior work to keep primalty and accountability, Attribution of work, as well as credit to primal author, since it's how open source works.
I'm simply stating that things need to be a bit more mature prior of being stated as supported. I have much respect for your work against Goliath. Not so much for the drama, fights and silo work. We don't compete here. We rely on each other's work. T480/t480s building in lbmk bubble doesn't pass reality way of how upstream nor other downstream projects builds, Leah. You can be angry at me for that, but that's the reality outside of "Leah's planet". Therefore, this shows a little bit of disrespect on upstream and other downstream projects, respecting upstream buildsystem. And I won't take the blame.
@libreleah I pointed to community effort. Come on.
Gentle reminder that this ecosystem is small and we should work together, for the benefit of the ecosystem.
I'm only representing desire from downstream, and pointed you to effort that is happening because upstream patch don't build. As usual you do as you want. I'm not fighting against you, I'm fighting for the benefit of all. You choose to pick a fight, I'm just pointing the obvious.
Heads is a payload of coreboot and doesn't pretend to be coreboot. Heads depends on functional coreboot ports. And require forks to build and not cause regressions for other boards. Just like Skulls, upstream, and all other forks who woukd have wanted to use 24.12 + t480/t480s.
You're being unreasonable. It's not my fight. People were misleaded by fake news saying t480 was supported by coreboot, creating demand and community effort. You're really hard to deal with @leah, I'm not your enemy.
On planet earth, community effort continues since they care more than upstream, patching patchset.
https://github.com/tlaurion/heads/pull/25
@libreleah Agreed that goals might be the same but approaches makes lbmk not fail on t480 because 24.12 not reused for other boards which should reuse 24.12. We're looping here.
Heads community members struggling and now passing more than 30h mentoring them understand lbmk and Heads where if patchset was ok upstream, it would be for Heads/Lbmk to do their own things as they want. Problem is, the patchset is incomplete for coreboot to review.
Anyway, putting the t480 aside, and postponing t480s until coreboot patchset under review is merged on my side, and taking note that a board can only be supported if part of a maintained coreboot fork (that is, that is not causing regressions for other boards depending on the same commit).
Heads port of t480 will stay where it is at https://github.com/linuxboot/heads/pull/1908#issuecomment-2704450527
I have not much more time to invest on this. As I said, I do not sell the t480, collaboration should happen upstream (for the bettering of the whole ecosystem) and debating lbmk/Heads buildsystem differences is out of scope of my message here, with all the others going in multiple directions as well.
If you are to invest into something to revise buildsystem buildstack, I would advise looking into StageX. I invested a lot of time into building a Nix docker image to fix reproducibility issues once and for all since Heads builds a lot of standard linux tools packed into initramfs, but StageX is working on the gnat/ADA boostrapping and once done, they will be feature complete and par with Nix for providing the proper docker image, and more (maybe even use StageX to produce libs and binaries to be packed into initramfs) without needing to build musl-cross-make, nor crossgcc buildstacks eventually; they could be packed into docker image and reproduced as needed)
Last note and repetition for clarity: each board under Heads specify a coreboot version (which corresponds to a fork/release), a linux version and configuration files for both. Then the boards are built by CI, with a dependency chain to reuse not only build stacks, but every build artifacts. This is accomplished because of the way the Make buildsystem does things, so no need for caching under coreboot by itself, all the boards will try to refresh build artifacts ad ski rebuuding them because fresh enough. This permits me to have a qube per project I work on and not waste time rebuilding anything else then initramfs which contains the scripts I work on under Heads, the rest is reused unless changed. And there is helpers in Makefile, and modules/* to clean things up if needed. Building fresh, I understand as a concept. But if reproducibility is guaranteed, is there a need to build fresh and waste CPU and disk space? Different ideologies, both valid. But once one tries to build roms on CI, one has to optimize those things because free tier builds are limiting, and Heads builds a lot of stuff.
LBMK fits LBMK needs. Heads fits Heads needs. Heads would improve by having things cached in a reproducible guaranteed cache system. It won't be Nix because Nix doesn't build things cached with muslc... But StageX does. And StageX was made with the goal of making firmware reproducibility a resolved problem.
Conference on ladt vPub: https://www.youtube.com/watch?v=9-xfccecwpo
Both Heads and lbmk permit to apply patches on top of a coreboot fork.
The difference between the two here is that lbmk builds the tree, clean, for each boards, where Heads applies the patches to a fork once, and each board reuses fork build artifacts;, building board specifics in a board specific artifact directory. That permits crossgcc, being the buildstack of each coreboot fork version to be built once, and also repro build issues upstream, economizing both disk space, cpu resource for user and CI.
In Heads goal of building fully functional roms, CI can build and stitch reproducible roms for each commit for end users to download directly from CI, for each commit, and see if a comit broke a built, for each commit. CI cache is reused, so that we don't waste CI resources either.
In the case of t480, the patch was made with lbmk in mind, not coreboot nor Heads, and breaks other thinkpads in coreboot upstream, trying to not only build for t480 but make sure t480 patchset doesn't break other boards. In this case, it breaks all other thinkpads, so prevent Heads from merging the PR. What you propose here is for libreboot and Heads to maintain a patchset not merged upstream; it might suit libreboot mindset, being more bleeding edge, and minifree, selling the t480, but not Heads. Heads tries to stay as close as possible to upstream forks, and pushes upstream projects to merge patches. Its long, not easy, but the right thing to do. The patches stays in a patch dir for everyone to see, per software version. In this case, patches/coreboot-24.12/*
I tried to apply the following patch without success instead of commenting thermal.asl
+diff --git a/src/ec/lenovo/h8/acpi/ec.asl b/src/ec/lenovo/h8/acpi/ec.asl
+index bc54d3b..a0408c8 100644
+--- a/src/ec/lenovo/h8/acpi/ec.asl
++++ b/src/ec/lenovo/h8/acpi/ec.asl
+@@ -331,7 +331,13 @@ Device(EC)
+ #include "sleepbutton.asl"
+ #include "lid.asl"
+ #include "beep.asl"
++
++#ifndef CONFIG_BOARD_LENOVO_T480
+ #include "thermal.asl"
++#else
++//#include "thermal.asl"
++#endif
++
+ #include "systemstatus.asl"
+ #include "thinkpad.asl"
+ }
Other non t480 fail to build, and I have no more time to spend on this. The community is interested, tried to reach libreboot and were seen as spammers.
Please fix your patchset upstream. People saw the t480 being "supported by coreboot" in a talk. People didn't understand it was a WiP patchset under coreboot. And here we are. 24.12 was december 2024 "release", there will be another one in 25.03... I do not have time to maintain patches on top of patches, Leah. My focus is not to be a coreboot distribution. My focus is to deliver reproducible roms to users needing accessible security, and improve that UX. There is no grub/seabios under Heads, my focus is to make upstream do the right thing and participate upstream, and make contributors participate upstream. Here, you stated loud and clear tha libreboot comes first before coreboot, I respect that. But the t480 patchset is the one too from upstream. That upstream patch needs to build, and then will be merged and then you won't have to maintain it either. And others will fix audio issues, nvidia etc. Otherwise its silo work, and i'm not interested in that anymore
---
Yes, there is different coreboot forks specified in a central place: modules/coreboot.
And there, the buildsystem says if it can reuse crossgcc of another fork to fasten builds for each commit. The idea here is that the user building one board, or multiple boards will get the same result, but CI building multiple boards based on the same fork will speed up builds massively.
d16 will move to fam15h fork from other community effort. I mentor now, I don't try to do everything myself. Just as here, trying tto collaborate with you so you fix what was brought up upstream. But up to now, you are upstream for t480.
The goal here was not to compare our buildsystems, simply stating that the patchset upstream will never be merged if it causes regressions building other boards. Libreboot can do what it wants, but needs to respect how coreboot works. Their CI does the same, and make sure that building a commit for a board won't break others. In current case, it breaks others and needs to be updated.
This needs to be fixed upstream at https://review.coreboot.org/c/coreboot/+/83274
Ideal would be to update patchset so it gets merged eventually so we don't maintain patchset downstream in all projects, nor need for board to build per fork either @libreleah. All 24.12 boards should be able to build per 24.12 fork + patchset, otherwise patchset will never get merged upstream. Have we lost track of getting things merged upstream as a primary goal here and decided to work in silo downstream forever?
I've abandoned helping community port after 30h Mentoring port unpaid until patchset is in order.
Conclusion is: if coreboot is not upstream or maintained and par with stock firmware on basic features and docs, Heads will not get involved in the future. Heads is a payload of coreboot, and does not pretend to be anything else than that. Heads rely in partnership with coreboot developers or boards maintained upstream and learned from its past mistakes doing otherwise.
Let me know when patchset upstream is fixed and doesn't, break other 24.12 boards builds.
Nice to read :)
Note that Heads doesn't rely on u-root though, that's linuxboot as a project.
Heads relies on the same ideology if linuxboot though :"let Linux do it". But as opposed to linuxboot which relies on single binary built from go code Ala busybox, Heads relies on scripts and native tools used typically under Linux.
---
Please let me know when the upstream patchset that has been partly reviewed is attacked so that it can eventually be merged, at https://review.coreboot.org/c/coreboot/+/83274
That patchset, when used to build other thinkpads, currently fails. Thsts probzbly why the review didn't get so much traction until now, the CI of coreboot probably reported failing back then, but those are no more available.
I replicated the failings because thermal.asl is commented, making all other thinkpads fail to build, and uncommenting this makes the T480 shortly boot, warn of thermal issues and power off, resulting in a brick.
The T480 effort is driven by Heads community that wanted the board and I decided to invest time to mentor for future ports as well. But this is a blocker. Maintaining patches over a patch for a board that has not been reviewed properly, has known issues unresolved and fails to build other thinkpads is unfortunately a blocker for downstram Heads support of the T480 as of now.
@libreleah feel free to comment there: if you saw the effort, you can as well collaborate there so that the community of technical enough board owners may want to speed up things upstream, and Lear what it means to get a board supported upstream.
--
This is a nice experiment. Thanks for your work there @mkukri!
