F41 Change Proposal: Enabling composefs by default for Atomic Desktops, CoreOS and IoT (Self-Contained)
Wiki - https://fedoraproject.org/wiki/Changes/ComposefsAtomicCoreOSIoT Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-enabling-composefs-by-default-for-atomic-desktops-coreos-and-iot-self-contained/123166 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == We want to enable composefs by default for Fedora Atomic Desktops, Fedora CoreOS and Fedora IoT. This makes the root mount of the system (`/`) a truly read only filesystem, increasing the system integrity and robustness. This is the first step toward a full ''at runtime'' verification of filesystem integrity. This change will be enabled only for the Bootable Container images of Fedora Atomic Desktops and not the classic ostree ones. == Owner == * [[User:jbtrystram| Jean-Baptiste Trystram]], jbtryst...@redhat.com * [[User:Siosm| Timothée Ravier]], si...@fedoraproject.org * [[User: pwhalen| Paul Whalen]], pwha...@fedoraproject.org == Detailed Description == Ostree based systems currently have `/usr` mounted as read-only and managed by ostree/rpm-ostree. The integrity of the content of `/usr` is only validated by ostree/rpm-ostree during updates and deployment operations, but not at "runtime". If a file is corrupted on disk (maliciously or not), it will only be detected if a full check is performed using `ostree fsck`. On those systems, the runtime root (`/`) of the system is currently mounted as read-write but with the `immutable` bit set (`chattr +i /`) to prevent accidental modifications. [https://github.com/containers/composefs composefs] is a new project that combines several existing filesystems (overlayfs, EROFS) to provide a very flexible mechanism to support read-only mountable filesystem trees, stacking on top of an underlying "lower" Linux filesystem. Using composefs, it will no longer be possible to mutate the underlaying file content that is part of the system (`/usr`) nor the layout of the root directory. It will result in I/O errors at the kernel level. The content is `/etc` and `/var` will remain writtable as it is today. This change is part of the [https://fedoraproject.org/wiki/Initiatives/Fedora_bootc Fedora Bootable Containers Initiative]. The `bootc` container images already enable composefs thus this change is to align existing variants to the new Bootable Containers defaults. It is tracked in: * Fedora Atomic Desktops: https://gitlab.com/fedora/ostree/sig/-/issues/35 * Fedora CoreOS: https://github.com/coreos/fedora-coreos-tracker/issues/1718 * Fedora IoT: https://github.com/fedora-iot/iot-distro/issues/52 This is the first step toward a full boot chain integrity, that will requiring signing the composefs metadata during composes and using Unified Kernel Images (UKI). See: https://gitlab.com/fedora/bootc/tracker/-/issues/14 As podman also use composefs to store containers layers, this enable deduplication of files between containers and host. This will result in less disk usage but also faster container startup and less memory use. See https://github.com/containers/composefs/issues/125 == Feedback == Nothing specific so far. We have the following "known issues": * Conflicts with `ostree-grub2`, which impacts Dual Boot support: ** https://github.com/ostreedev/ostree/issues/3198 ** We will remove ostree-grub2 from Fedora Atomic Desktops bootable container images ** Related to: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd ** We can do this ''now'' for the container images as they are not officially released for Fedora, and generally ''newer'', so it's more likely that the bootloader on those systems are already BLS capable. ** We can not do this for "classic ostree" Atomic Desktops yet as we need a transition period with bootupd enabled by default before removing ostree-grub2. ** However with the recent Secure Boot issue (https://github.com/fedora-silverblue/issue-tracker/issues/543) forcing everybody to manually update their bootloader, we might be able to shorten this transition period. ** See for Dual Boot: https://github.com/fedora-silverblue/issue-tracker/issues/530 * No longer possible to create root level direcotries (`chattr -i` workaround): ** Requires derivation, thus the container flow ** https://github.com/coreos/rpm-ostree/issues/337 ** Alternative: https://github.com/ostreedev/ostree/pull/3114 ** Might impact Podman Desktop for Fedora CoreOS. They will likely disable it until a solution is found. * Issues with kdump: ** https://bugzilla.redhat.com/show_bug.cgi?id=2284097 ** https://gitlab.com/fedora/bootc/tracker/-/issues/19 == Benefit to Fedora == This will increase the robustness of image based Fedora systems and prepare them for future increased security guarantees. This will align the existing imag
F41 Change Proposal: acpica-tools: Deprecate Big Endian Support (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/Acpica-tools_Deprecate-Big_Endian_Support Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-acpica-tools-deprecate-big-endian-support-system-wide/123164 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The acpica-tools package has supported big-endian architectures for several years, but it has few uses. For Fedora 41, remove all of the patches for big-endian support and remove s390x from the list of supported architectures. == Owner == * Name: [[User:ahs3| Al Stone]] * Email: a...@fedoraproject.org == Detailed Description == For many years, the acpica-tools package has supported the big-endian s390x architecture, despite ACPI being a little-endian ''only'' standard. This made sense originally, as some s390x packages had to have mechanisms for dealing with ACPI tables, and there were several packages with build dependencies since they created ACPI tables. Neither of these is really true any longer. What's more, big-endian support has always had a fairly high cost. In the first place, upstream wants nothing to do with big-endian support; it is completely irrelevant, despite several attempts to get them to accept it. Secondly, every release of the upstream source requires significant backporting of the big-endian patches, creating new patches to support new features of, or changes in, the ACPI standard, and then testing and debugging the results. In the last ten years, the least amount of time to do this was two full days; the longest it has taken has been two full weeks. One has to plan for at least a week. And finally, the need for big-endian has diminished considerably. At one point, some virtualization functions required these tools so that there was no virtualization on s390x without them; again, this is no longer true. The actual changes to the acpica-tools package will actually simplify maintenance significantly. The change itself is fairly straightforward: remove the big-endian patches, and add s390x to ExcludeArch. == Feedback == This proposal was actually prompted by a recent PR on acpica-tools requesting a way to ignore the big-endian patches: [https://src.fedoraproject.org/rpms/acpica-tools/pull-request/5]. Upstream has ''never'' accepted big-endian support. Should this proposal be accepted, it would be one way of meeting the request behind the PR, however. Some discussion has occurred with s390x supporters (both recently, and in the past) that would indicate this would be something that is not ideal (no one likes to lose packages), but doesn't really create problems. Part of the reason for making this proposal is to be sure I'm not missing something. == Benefit to Fedora == The primary benefit to this proposal is that it simplifies maintenance significantly. Of the 69 patches for the package, 49 can simply be removed. The longest and most difficult builds will not be needed; the s390x testing that always takes most of the package update time will no longer be needed either. This will make it easier to ensure that acpica-tools more closely matches upstream than has been possible recently, producing a higher quality package quicker. == Scope == * Proposal owners: The actual changes to the acpica-tools package will be to remove the big-endian patches, and add s390x to ExcludeArch. This is quite straightforward. * Other developers: Based on an initial investigation, it appears that most changes will be to simply exclude s390x. So far, the only packages that seem to be affected are hw-probe, vim-syntastic-asl, and edk2. There appears to be some use outside of Fedora (xorg-x11-drv-nvidia, their proprietary drivers, for some reason). * Release engineering: This change only affects the specific packages mentioned so far. * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == Only s390x systems would notice a change in that this package would no longer be available. == How To Test == There is a test suite included in the acpica-tools package that is always run as part of the %check step in the spec file. No new testing should be required. == User Experience == Only s390x systems would notice a change in that this package would no longer be available. == Dependencies == The packages hw-probe, vim-syntastic-asl, and edk2 depend on acpica-tools. However, to make the changes to acpica-tools, there are no other dependencies. == Contingency Plan == * Contingency mechanism: do nothing; the existing f40 package can continue to be used. * Contingency deadline: beta freeze * Blocks release? No == Documentation == These changes actually put the Fedora version of the package back into a state where it matches upstream more closely. == Release Notes == -- A
