Thanks for speaking up. As a heavy x86 user, I agree this article is due for some attention. Do you plan on updating the wiki yourself or would you like me or someone else to do it on your behalf once you’ve finished “workshopping” the copy?
3 Likes
One thing I am thinking about when reading the wiki sub part about uefi and secure boot is that the part with secure boot seems very old. And the contents in the Github branch the link is connected to is not updated for 8years!?
Are those secure boot packages even alive anymore and does they even work with todays kernels. If we want secure boot I think it should be included in the official packages in some way?
1 Like
secure boot support is very unlikely.
- it needs very expensive certificates from Microsoft
- the first stage bootloader (usually shim) would need to be signed by Microsoft for each build, this takes weeks+ for each iteration
- OpenWrt would need to deploy its own CA for trusted grub, kernel, qemu, kexec, etc. OpenWrt-signed binaries and integrate that into the buildbot infrastructure
Building OpenWrt from source, sorry, no longer possible.
Changing kernel options, sorry, no longer possible.
PRs for kernel updates, sorry, no longer possible.
Read 'no longer possible' as 'very hard', developers would have to create their own keys, enroll them into UEFI, build everything using them, etc. pp. - technically possible, but you'd reduce the number of contributors pretty much to zero.
3 Likes
@joshenders
It'd be great if you or someone with a wiki account can update it. And in my case, I am mostly done with the information that I know of. If there is going to be more editing, it will be from the suggestions of other community members. 
1 Like
I guess the practical solution regarding secure boot is to disable it in the motherboard boot setting. In my simplified understanding, it is there to ensure only credible stuff can boot the device; and in its absence, we take the responsibility of decide if an image is trustworthy (by verifying checksums, etc).
2 Likes
In some kind of theory the idea seems to be that the cert key for the “my” build are in the bios key bank and are verified with the encrypted software at boot to see that no malware has included it self between bios start and boot time.
That is possible, but would need quite considerable changes to the build process of grub (maybe introducing shim, but not strictly necessary if you enroll your own MOK keys), kernel, a couple of other packages (procd?) and change the image recipe - possible, but not exactly fun.
That is the thing with the instruction on the wiki for secure boot. That link to a github repository that was made 8years ago and hasn’t been touched since then. That means the packages that are downloaded are also 8years old.
So I doubt anything of that work with current OpenWrt.
Last time I used sysupgrade on EFI and virtualized x86-64 couldnt boot system and lost data/history from additional packages..
Is it now possible to do that using the regular sysupgrade and not lose data?
You mean configurations, or stuff like rrd logs? If the former, then LuCI ASU and CLI auc work fine for keeping your installed packages and their configs. (This, of course, assumes no major changes between old and new installs.)
The latter is more problematic and package-specific (see thread on maintaining the aforementioned rrd database as an example: Saving dynamically-generated files during sysupgrade).
1 Like
I'll review this thread in more detail, test upgrading a few of my routers, and then update the wiki. Thank you for your contribution!
1 Like
Oh my golly gosh. I read that wiki article a while ago, saw it was quite involved, was planning to set some time to fully comprehend it (quite comfortable with resizing partitions on a normal linux machine, but I also fully understand the boot process of a normal linux machine, hardware or VM).
Added complication was that all other hardware types have a dedicated sysupgrade image. Doesn't help that the sysupgrade page linked to can't filter for x86, but there is no dedicated sysupgrade image in the x86 download tree. The hint above to just download the same image type you started with was the hint I needed. Now which image did I install with? Fortunately, my original wget command was still in my commandline history because my history is infinite these days. df -T can probably give a hint as to what you originally installed too.
All seems to be working... Just reinstated the same environment via my ansible playbook, and all seems to be good. If it's not, I just revert my VM snapshot 
That's another thing auc and LuCI Attended Sysupgrade do for you: they reconstruct what is needed on the fly, so you don't have to remember...