On Sat, Mar 4, 2023 at 7:31 PM David Michael <fedora.dm0@xxxxxxxxx> wrote: > > On Sat, Mar 4, 2023 at 5:51 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Sat, Mar 4, 2023 at 12:41 PM David Michael <fedora.dm0@xxxxxxxxx> wrote: > > > Hi, > > > > > > Firecracker[0] is a minimal virtual machine manager (a la QEMU) > > > written in Rust that uses KVM to start Linux VMs extremely quickly and > > > securely. It is used by AWS Lambda and Fargate among other things to > > > make VM startup time comparable to containers. I've built it for > > > Fedora x86_64 and shared it in a Copr repository[1] which includes > > > some example commands for starting VMs. > > > > > > Making it build for Fedora required changes across a few components, > > > so I'm writing to ask if this is acceptable for inclusion in Fedora. > > > The Copr specs are all dumped in a Git repository[2] for readability. > > > Changes include: > > > > > > - The musl package adds /usr paths for compatibility with the > > > compiler --sysroot option. > > > > As the musl package maintainer, I don't particularly want Fedora > > packages depending on it unless they absolutely have to. I originally > > maintained it in Copr, but brought it into Fedora for the Enarx folks. > > I still maintain that generally you don't want to use this unless you > > *really* know what you're doing and can deal with the consequences of > > using an alternative libc. > > It sounds like there are enough issues with musl in Fedora that glibc > will have to be used. > > > That said, the changes you make are not currently compatible with the > > packaging guidelines. Can't you just use --prefix /usr/<target> > > instead? > > It was for using --sysroot directly on gcc calls. > > > > - The rust compiler adds musl target subpackages. > > > > This will require discussion with the Fedora Rust SIG. > > > > > - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be > > > usable as a guest. > > > > This will require talking to the kernel maintainers to add the flag. > > Okay, I'll ask about getting this applied even if Firecracker is not > included in Fedora. It still might be useful to use for a quick guest > kernel, and the option is just to support a command-line parameter[0], > so it shouldn't be disruptive. > > [0] https://github.com/torvalds/linux/blob/v6.2/Documentation/admin-guide/kernel-parameters.txt#L6697 > > > > - About two dozen Rust crates must be added to Fedora (but a handful > > > are just new versions of existing packages). > > > - Unrelated, but in the Copr repo anyway: The musl package is fixed > > > to allow multilib installs, and Rust includes both 32- and 64-bit > > > targets. > > > > > > I used upstream-preferred settings when adding things, but they may be > > > in conflict with Fedora guidelines. Here are some concerns: > > > > > > - Firecracker can be built with Fedora's libc (glibc), but it is > > > officially unsupported upstream[3]. Functionality would be harmed by > > > not using musl, e.g. seccomp filters are not used. > > > > Why not drive this to be fixed upstream? Also, openSUSE builds > > Firecracker against glibc and I see the seccomp stuff is also produced > > and shipped[1]. I am not sure whether this means openSUSE's package is > > broken or something else. > > > > [1]: https://code.opensuse.org/package/firecracker/blob/master/f/firecracker.spec > > I can look into what they're doing more thoroughly later, but I would > assume they are just running with the empty seccomp filter. I am > aware of two issues with glibc: The jailer program allegedly does not > work with non-musl (although it builds) and is disabled upstream[1], > and there is no non-musl seccomp filter[2][3]. > > [1] https://github.com/firecracker-microvm/firecracker/pull/2125 > [2] https://github.com/firecracker-microvm/firecracker/blob/v1.3.0/src/vmm/build.rs#L25 > [3] https://github.com/firecracker-microvm/firecracker/tree/v1.3.0/resources/seccomp > > > > - Upstream Rust wants musl targets to be statically linked by > > > default[4]. It can be changed by patching (Gentoo does this) if > > > dynamic linking is still a priority with Rust binaries, but I haven't > > > tested that. > > > > As in musl is statically linked into the binaries? Or the Rust code is > > statically linked. The former is not okay, the latter is what we do > > already. > > The former, the musl targets produce static binaries by default. > > > > - Firecracker uses two crates forked from crates.io, but they are > > > not vendored/bundled nor published to a registry. I'm currently > > > manually bundling them as if they were vendored to avoid package name > > > conflicts since nothing else uses them, but I don't know the preferred > > > way to deal with those. > > > > > > > That's probably the right way to deal with it. > > > > > So does any of that sound like a showstopper for being included in > > > Fedora? Is there any other interest in the project from the > > > community? > > > > > > > It'd be interesting to have in Fedora, for sure, but this should be > > done as an opportunity to bring our integration concerns upstream. > > Okay, thanks for all the feedback. I interpret this as essentially > requiring the use of the glibc Rust target for inclusion in Fedora, so > the changes on the Fedora side would be reduced to adding a couple > dozen crates and ideally supporting the kernel as a guest. That > shifts the bulk of the work to getting glibc fully supported upstream, > and running a not-quite-as-secure build until then. I'll investigate > this, and if there are no other blockers, maybe I can start sending > review requests for the glibc build. > That sounds great! I look forward to seeing Firecracker in Fedora. :) -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
