Build with the musl library to generate a static binary

[sdake]

Hello,

Thank you for providing packaging. I have been looking for something pre-baked for some time!

I have read that cloud-hypervisor has an interest in going expressly to a a musl build. Can you advise how to create a musl build ahead of 0.26? I think musl build is the right direction for the project as well.

See: cloud-hypervisor/cloud-hypervisor#4356 for more details.

[sdake]

After rereading the RFC, I noticed that the proposal was reverted, to provide both musl and glibc binaries. Still, it would be pretty awesome to provide a musl specific deb. Any thoughts on how this can be achieved?

Thank you.
-steve

[weltling]

Thanks for keeping an eye on this. It's correct, there's currently no musl packaged which has been excluded for simplicity. Probably one could pull in the existing pieces and compile musl statically to produce another binary within the same package. Or fork the specs and create a parallel package that would be a replacement for glibc based builds.

This probably should be fine to pursue as long as there's ask. Just to clarify the use case - when one would use CH linked with musl, the glibc one would actually not be needed on the same system? And vice versa. And also then, musl could be done just in the same manner dynamically linked. Or is there a need to have both at the same time on the same system?

Thanks

[sdake]

Many people may have different perspectives.

I want cloud-hypervisor in a static library, recognizing the rest of the system on which it runs will continue, for the foreseeable future, to be linked against glibc. That said, I don't want a glibc variant of cloud-hypervisor installed at the same time, which I think is the interest of your question.

What I'd like to do is something like apt install cloud-hypervisor-static and receive a static version.

Cheers,
steve

[weltling]

There is a previous work located here:

https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/rpm/cloud-hypervisor.spec#L80

That suggests just packaging into a sub folder. Perhaps cleaner would be indeed having a separate package for musl that would conflict with glibc. I'd probably plan to do some more home work to understand this better first. For better understanding also, what do you think would be other advantages musl over gilbc, besides musl is the only way to have a static binary as per the linked issue discussion. The binaries provided by this repos already targets the specific distribution and version.

Btw. that also what i was wondering as well when asking about static build, as there doesn't really seem to be a distro based completely on musl. Still, if there's an opportinity to have a shared musl from the distro, it probably should be preferrable. Further more, AFAIK there are hard policies that might harden later spec upstreaming, if some static linking is involved. This needs to be weight, too.

Thanks

[sdake]

@weltling My use case is cloud-specific, with a very very small footprint hypervisor, not a full-blown distribution. In this case, static is easier to reason about during servicability events.

Cheers,
-steve

[sdake]

Regarding the bundling of libraries and the various requirements to unbundle in distributions such as Fedora, I agree for packaging to make it into the main repositories, these problems need to be solved. I simply want a way to hand a "package" to a peer so they can run cloud hypervisor without looking at a static binary. Shipping around a static binary has limitations, versus packaging.

Cheers,
-steve

[weltling]

ACK, so this sounds like there's not really an advantage of using musl vs. glibc in the functionality. The only point on using musl is to have static binaries (with all their pro and contra).

Shipping around a static binary has limitations, versus packaging.

Could you expand a bit more on this? I mean, there are obvious points like for example capabilities not being portable and thus carrying cloud-hypervisor even static int a tarball would still need additional steps compared to just defining a post install action in a package. Is there more of this kind from your experience?

Thanks

[sdake]

Packaging provides the following advantages:

• The license of the software and all transitive dependencies can be recorded
• The author of the software and all transitive dependencies can be recorded
• The software distribution can be signed
• Man pages, yes antiquated as they may be, can be shipped with the package

There are many more advantages to packaging. But I am not here to defend packaging or static. SImply state that packaging of a bundled binary provides overall better security and compliance then simply shipping a binary to a third party.

I hope that helps
-steve

[sdake]

@weltling also, are you aware of any technology in Linux proper that will verify signed binaries? That would be a pretty cool feature. I can understand why such a feature may be rejected upstream, but I don't track all of upstream actions.

Cheers,
-steve

[weltling]

@sdake yeah, there are pro/contra. As i understand now from the description you gave, it is more about distributing just some binaries versus packages, so not specific to static binaries only.

Regarding signed binaries - i wouldn't know about such a mechanism on Linux. Depending on the use case, some integrity checks are available. For some cases dm-verity is suitable, but not if that's an RW filesystem. I recall also https://microsoft.github.io/ipe/ my colleges worked on, but no experience so you'd have to explore if it sounds interesting. But i think in general - such a mechanism requires one to own the device and the system which would start with some kind of secure boot.

For the static binaries then - i'll plan to work on it, most likely will come to it in the second half of September or October. Otherwise, if someone has cycles to contribute, so it might happen sooner. In between, there are still the repositories with the glibc based CH.

Thanks

[weltling]

@sdake despite my expectation, i don't happen to find a free slot to implement this in the way so it would actually build a static binary. This requires an extra musl rust-std to be installed along with the glibc one. Thus, it requires to override and maintain any distro default rust. While I have to maintain rust for Debian and Ubuntu, default Rust is used for any other distros.

At the current stage, the repos provided by OBS can be added to install Cloud Hypervsior linked against the corresponding distro libs. On could also sure package the officially released static binaries from Cloud Hypervisor releases, if that helps. If someone wants to contribute such specs, the repo is open for that. Otherwise seems adding a repo should solve the most of the use cases.

Thanks