TinyCorePure : rootfs provides system libs+ldd. Pack them under systemlibs.tcz?

[insurgo]

Hello there! First post so sorry if not using proper vocabulary.

As some of you may know, firmware can provide base for trusthworthy, user, on-demand, runtime environment.

Firmware is nowadays really complex with UEFI, but linuxboot can be used to replace DXE by linux there.
On legacy systems, Heads (coreboot+ linux kernel+ busybox (or alternative)) gives the rudiments needed to then do whatever one wants there at the condition of having a network connection (which in a current PoC works perfectly fine using Android phone over USB to tether internet and have TinyCore downloaded and ran in memory or have tcz packages downloaded locally for persistence and reusage.

Long story short.
u-root (aimed to be a busybox replacement) added tcz module a while ago (advertising 8.x) under https://github.com/u-root/u-root/blob/main/cmds/exp/tcz/tcz.go
exp/tcz didn't implement all tcz requirements, and I opened an issue upstream to fix tcz's post-install scripts under https://github.com/u-root/u-root/issues/2665


But for the issue at stake here, considering firmware space is precious, for tcz to be actually working out of the box today, u-root currently needs to pack the following from decompressed rootfs64.gz: lib/ld-linux-x86-64.so.2 lib/libanl.so.1 lib/libc.so.6 lib/libdl.so.2 lib/libm.so.6 lib/libpthread.so.0 lib/librt.so.1 usr/lib/libgcc_s.so.1 lib/libcrypt.so.1 lib/libutil.so.1

This forum post aims to test the waters from developers here (I tried the irc channel that pointed me here) to see root64.gz libraries and ldd interpreter could be packed under an additional tcz package. That way, instead of deduplicating those (Heads modules are built with musl-cross-make, so we have libc and ldd from there), we could simply download that systembase (or rootfs_systemlibs or whatever) and Heads could consider using tinycore there.

I see packages lacking for the usage Heads would want to do of tinycore though.
cryptsetup-reencrypt is missing amongst others, but if there is willingness, I think tinycore could have a future in firmware space. Reproducibility of builds etc (BoM  being a thing as well) could go a long way. Otherwise, a parallel PoC is attempted against Nix (https://github.com/DeterminateSystems/nix-installer).

The important part for Heads (and firmware) is to reduce tools inclusion, since it can measure and attest of external states on which it could then depend. For Heads, having tczs packages under /boot, for which a detached signed digest would verify integrity of the files prior of considering them as part of verified state, could be a lifesaver and permit to extend, on demand, functionalities. Tinycore is amazing and I wish I jumped into its boat way before. I hope its not too late.
I already took advantage of strace, file and other tcz in my non-usable PoC to test tinycore discovered problems, but the PoC itself can only run under qemu, since consumed space by u-root (not compiled with tinygo as of now) plus the need of packing rootfs64.gz ldd and libraries is too costly to apply the PoC as of now to actually play along with real life space considerations of sandy bridge(8mb SPI)/ivy bridge (12mb SPI), where supporting lower end space constraints is a requirement which requires finding solutions like tinycore/nix/whatever will fit the bill best.

Any opinion welcome, I will wait for updates to reach my mailbox and come back here, and looking forward to see who are interested into those kind of synergies.

[curaga]

This requirement, separating libc etc, sounds like it'd be a downside for all current TC usage. We also don't do reproducible builds, which may make TC not an ideal platform for your use.

If you meant having them as a separate file, keeping the current rootfs as is, this would encourage constantly re-downloading it from our servers, which is an usage model we discourage. If you were to host it on your own servers, that'd be totally fine, but then you could do the repacking easily.

TC has been used in the BIOS chip before a few times, but they were custom setups, remasters with a cut-down kernel etc. This was also for recovery/web browsing purposes, not a cryptographically verified secure env.

(as an aside, why are you using Go for something space-conscious? Last I used it, their hello world binary was 1mb+...)

[patrikg]

You can use upx to pack the Large GO applications.
If the space is consider you.

[insurgo]

If you meant having them as a separate file, keeping the current rootfs as is, this would encourage constantly re-downloading it from our servers, which is an usage model we discourage. If you were to host it on your own servers, that'd be totally fine, but then you could do the repacking easily.

TC has been used in the BIOS chip before a few times, but they were custom setups, remasters with a cut-down kernel etc. This was also for recovery/web browsing purposes, not a cryptographically verified secure env.

My suggestion was not to replace rootfs, but duplicating libraries into a seperate package, that would be downloaded for recovery use cases.
cryptographically verified secure env would not be relevant if running from ram, but downloaded packages could also be cached locally, which is what u-root's exp/tcz is doing right now (with bug referred still unfixed to run post-install script to be fully functional on u-root's side).

As of today, tcz is the most interesting approach to Heads, since each tcz is seldom, *outside* of the libc ldd requirements expected to be in rootfs, so basically, ran from ISO. This would open the door of being able to reuse tce-load principles, basically, but from firmware.
Basically, I was talking about repackaging a seperate systemlibs.tcz every time a rootfs is being built. Nothing less nor more, encompassing basically every *.so.* there is under current rootfs. Makes sense?

Can you refer to such firmware applications of tcz? I would be interested into looking how they did that.

Thanks for your time. As said, this project is really interesting, wish I was aware of its existing before.

[curaga]

Sorry, I don't have links for those. I don't think some were ever public, and others were on blogs that may no longer be online. You may find something googling for tc coreboot linuxbios etc.