Wiki - https://fedoraproject.org/wiki/Changes/ConfidentialVirtHostIntelTDX
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-confidential-vir…
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 ==
This change will introduce support for Fedora virtualization hosts to
run confidential guests on suitable Intel TDX hardware.
== Owner ==
* Name: [[User:berrange| Daniel Berrange]]
* Email: berrange(a)redhat.com
== Detailed Description ==
Fedora has provided support for launching confidential virtual
machines using KVM on x86_64 hosts for several years, using the SEV
and SEV-ES technologies available from AMD CPUs, and since Fedora 41,
using the SEV-SNP technology. In the Fedora 42 release, support for
the Intel SGX platform was introduced, and this change builds on that
work to allow creation of Intel TDX guests on Fedora hosts. Intel TDX
provides confidential virtualization functionality that is on a par
with the recent AMD SEV-SNP support.
== Feedback ==
TBD
== Benefit to Fedora ==
* This change allows creation of Intel TDX guests on Fedora
virtualization hosts when suitable Intel TDX hardware (EmeraldRapids
or newer Xeon CPUs) is available
== Scope ==
The vast majority of work will arrive in Fedora automatically via
regularly performed rebases to new upstream releases.
* Proposal owners:
** Rebase QEMU to 10.1.0 release (GA ~ Sept 1st, release candidates
available before Fedora freeze)
** Rebase libvirt to 11.8.0 release (GA ~ Sept 1st, release
candidates, or patch backports, available before Fedora freeze)
** Write SELinux policy for 'qgs' daemon (qgs_t) to allow QEMU
(svirt_t) to talk to it for attestation.
** Enhance virt-install to allow creation of TDX guests and arrange
for new release & rebase, or patch backport
* Other developers:
** Rebase kernel to >= 6.16 (TDX host patches targetted for 6.16
merge window in 1st week of April)
** Merge new SELinux policy rules for 'qgs' daemon and QEMU
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
==Alignment with the Fedora Strategy ==
* Fedora will be demonstrating leading / state of the art integration
of Intel TDX feature into a Linux distribution's virtualization host
stack.
* Fedora will be providing the fully OSS host-to-guest stack for
confidential virtual machines on modern Intel x86_64 Xeon hardware.
== Upgrade/compatibility impact ==
None expected, the new functionality doesn't impact on existing
functionality in Fedora
== Early Testing (Optional) ==
N/A
== How To Test ==
Full details TBD - high level intent is:
* Check whether the host hardware configuration is capable of
supporting TDX (very strict DIMM population requirements, along with
EmeraldRapids or newer Xeon class CPUs)
* Configure EFI firmware to enable use of SGX and TDX
* Disable hibernation support in host kernel via adding 'nohibernate'
to /etc/default/grub and re-creating grub.cfg
* Use 'virt-install' to provision an confidential VM
* Request an attestation report from the guest using sysfs
* Validate the attestation report on a trusted machine using <some tool>
== User Experience ==
* Virtualization host owners will be able to launch confidential
virtual machines using Intel TDX technology
* Guest owners will be able to prove that their OS is running in a
Fedora host confidential virtual machine protected by Intel TDX, by
performing a guest attestation
== Dependencies ==
* Fedora SELinux maintainers need to review & merge new policy to be
submitted by proposal owners for the 'qgs' daemon
* Fedora kernel maintainers need to rebase to >= 6.16 (should be
happening regardless, as normal kernel maint work)
* virt-install owner to do rebase or accept MR to backport TDX support patches
== Contingency Plan ==
* Contingency mechanism: Ship whatever was ready in time, and leave
rest until Fedora 44
* Contingency deadline: Change completion deadline
* Blocks release? No
== Documentation ==
* NBD: document hot to validate hardware pre-requisites
* [https://fedoraproject.org/wiki/Virt/SGX#Firmware_configuration
Configure the Firmware to enable SGX]
* TBD: document general host kernel/OS setup tasks (prior art
https://sig.centos.org/virt/tdx/host/#verification/)
* TBD: document one-time setup tasks for attestation on multi-socket machines
* TBD: document how to use 'virt-install' to provision a guest
* TBD: document how to query the attestation report in the guest
== Release Notes ==
Fedora virtualization hosts running on suitably configured Intel Xeon
hardware, have the ability to launch confidential virtual machines
using the Intel TDX feature.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/CMake_drop_install_vars
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-cmake-drop-non-s…
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 ==
Drop variables that are not standardized by CMake in the `%cmake`
macro. The dropped options are`-DINCLUDE_INSTALL_DIR`,
`-DLIB_INSTALL_DIR`, `-DSYSCONF_INSTALL_DIR`, `-DSHARE_INSTALL_PREFIX`
and `-DLIB_SUFFIX`. Affected projects are tracked in
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-drop_vars/ this
copr repo], please check if your packages are failing there.
== Owner ==
* Name: [[User:lecris| Cristian Le]]
* Email: fedora(a)lecris.me
== Detailed Description ==
The variables `*_INSTALL_DIR`, `SHARE_INSTALL_PREFIX` and `LIB_SUFFIX`
have been passed by default in the `%cmake` macro, however these
variables have never been standardized by CMake, and thus the
definition and usage of these variables is up to the individual
project, e.g. it is unclear if `INCLUDE_INSTALL_DIR` is meant to be
the absolute or relative path.
Since CMake 3.0, the standardized installation path is defined in
`GNUInstallDirs` and many distributions and packaging environment have
been defining their standards in that module. Upstream projects should
be migrating to this standard instead.
=== Migration ===
{{admon/tip | Compatibility with fedora releases | Any proposed
changes here are compatible with any CMake versions and can be
included at any point and backported to any Fedora release.
<br>The corresponding
[https://src.fedoraproject.org/rpms/cmake/pull-request/50 cmake PR]
will not be merged until the affected packages are patched.
}}
* As a quick fix, the affected package can manually add the
corresponding variables, specifically:
%cmake \
-DINCLUDE_INSTALL_DIR:PATH=%{_includedir} \
-DLIB_INSTALL_DIR:PATH=%{_libdir} \
-DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \
-DSHARE_INSTALL_PREFIX:PATH=%{_datadir} \
%if "%{?_lib}" == "lib64"
%{?_cmake_lib_suffix64} \
%endif
...
* Upstream projects can alter the defaults of these variables based on
`GNUInstallDirs` variables, e.g.
project(...)
include(GNUInstallDirs)
set(LIB_INSTALL_DIR "${CMAKE_INSTALL_LIBDIR}" CACHE PATH "")
* To replicate the `LIB_SUFFIX` the project could use:
include(GNUInstallDirs)
if(CMAKE_INSTALL_LIBDIR MATCHES "lib64$")
set(LIB_SUFFIX 64)
endif()
== Benefit to Fedora ==
* Avoid packaging issue due to the current assumption that the the
paths used are meant to be absolute paths.
* Encourage upstream build system modernization and standardization.
== Scope ==
* Proposal owners:
** Drop the non-standard CMake variables
** Try to propose appropriate fixes as much as possible
** Assist the more complicated migrations and be a point of contact
for upstream issue
* Other developers:
** Adjust the spec file at least with the minimum quick fix. See [[Migration]].
** Contact upstream to request/suggest the more long-term solution
described in [[Migration]]. Change owner is available if upstream
requires more specialized CMake discussions.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Affected packages would be FTBFS (in the tracked
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-drop_vars/ copr
repo]) and would require patching before the corresponding
[https://src.fedoraproject.org/rpms/cmake/pull-request/50 cmake PR]
can be merged.
== How To Test ==
A copr repo will be provided with these variables dropped. Use it to
try local builds, e.g. using:
copr mock-config lecris/cmake-drop_vars fedora-rawhide-x86_64
If the build is successful, that should be sufficient.
== Dependencies ==
There are currently 309/2359 packages affected gathered and built
using mass-pre-build in
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-drop_vars/
copr], [https://copr.fedorainfracloud.org/coprs/lecris/cmake-drop_vars.checker/buil…
many of them] are previously FTBFS in rawhide.
== Contingency Plan ==
* Contingency mechanism: N/A (no deadline set)
* Contingency deadline: No deadline necessary yet
* Blocks release? No
== Documentation ==
* [https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html
GNUInstallDirs]
* Example migrations: [https://github.com/gnuradio/gnuradio/pull/7768
complex project]
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/CMake4.0
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-propopsal-cmake-4-0-syste…
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 ==
Update CMake to version 4.0. This version breaks compatibility with
projects that specify `cmake_minimum_required` with ''only'' a lower
bound less than `3.5`. Affected projects are tracked in
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0/ this copr
repo], please check if your packages are failing there.
== Owner ==
* Name: [[User:lecris| Cristian Le]]
* Email: fedora(a)lecris.me
== Detailed Description ==
Projects built with different major versions of CMake are generally
compatible with each other due to the use of `cmake_minimum_required`
and CMake policies that define how the build will behave, `OLD` or
`NEW` behavior, with the minimum version given to
`cmake_minimum_required` specifying that policies defined up to that
version should use the `NEW` behavior and policies defined from that
version onward use the `OLD` behavior.
Every so often a new CMake version drops support for `OLD` policies,
and in CMake 4.0 all policies before 3.5 are dropped (this is actually
the first time the `OLD` policies are being dropped). This requires
various projects to check if their build will be affected by a
rebuild, and adjust the CMake files accordingly.
Other changes:
* Various compatibility layers have been provided during the CMake 3.x
packaging, but as the technologies improved and since CMake maintains
general compatibility across major versions, these compatibility
layers have become unnecessary and will be gradually removed.
** The `%cmake4*` macros are not provided and `%cmake3` macros still
alias the `%cmake` macros.
** `/usr/bin/cmake3` is no longer provided and for the time being
`/usr/bin/cmake4` is an additional symlink to `/usr/bin/cmake`.
Dropping `/usr/bin/cmake4` will be raised in a future change proposal.
** The `cmake.spec` file will continue to have `Provides: cmake3`, but
there will '''NOT''' be a `Provides: cmake4`.
=== Migration ===
{{admon/tip | Compatibility with fedora releases | Any proposed
changes here are compatible with any CMake versions and can be
included at any point and backported to any Fedora release.
<br> The corresponding
[https://src.fedoraproject.org/rpms/cmake/pull-request/49 cmake PR]
will not be merged until the affected packages are patched
}}
Quick solution: Adding an environment variable or `-D` option
`CMAKE_POLICY_VERSION_MINIMUM=3.5` would unblock the builds in 90% of
the cases, but this is not 'generally' recommended because it is not
upstream friendly, and can hide build failures if the
`cmake_minimum_required` is hard-coded in the files distributed in the
`-devel` package.
In most cases the required change is very minimal, just requiring to
update '''all''' occurrences of `cmake_minimum_required` e.g.
cmake_minimum_required(VERSION 3.12...4.0)
It is ''highly'' recommended to include a higher-bound which '''does
not''' mean that building with any higher CMake version will break,
instead if the project is built with any version in between these
bounds, it will automatically use the `NEW` policy. This will help in
the future when needing to bump the minimum version again since it
will be safe to update the minimum up to the current higher-bound.
The versions to be used are up to upstream's discretion for which
versions they want to test and support, and technically the following
is also acceptable:
cmake_minimum_required(VERSION 2.8...4.0)
There may be unforeseen consequences due to the change in the policy,
for example with `CMP0028` change, builds can fail if the library or
other target have `::` in their name. These however are generally very
specialized edge-cases, so for the most parts, a simple change of
`cmake_minimum_required` is sufficient. Still it is best to consult
with upstream's testing infrastructure.
== Benefit to Fedora ==
Availability of CMake 4.0 for the user to develop, and upstreaming
CMake 4.0 compatibility patches.
== Scope ==
* Proposal owners:
** Build CMake 4.0 and impact-check affected projects
** Try to propose appropriate fixes as much as possible
** Assist the more complicated migrations and be a point of contact
for upstream issue
* Other developers:
** Adjust the package to update the `cmake_minimum_required`. See [[Migration]].
** Contact upstream to request/suggest the more long-term solution
described in [[Migration]]. Change owner is available if upstream
requires more specialized CMake discussions.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Affected packages would be FTBFS (in the tracked
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0/ copr repo])
and would require patching before the corresponding
[https://src.fedoraproject.org/rpms/cmake/pull-request/49 cmake PR]
can be merged.
== How To Test ==
A copr repo will be provided with CMake 4.0 rebuilds. Use it to try
local builds, e.g. using:
copr mock-config lecris/cmake-4.0 fedora-rawhide-x86_64
If the build is successful, that should be sufficient, but check your
reverse dependencies to see if the `-devel` package files are also
built correctly.
Most of the policies should result in build/test failures if the
package was relying on an outdated `OLD` behavior, but there are some
that may have more subtle behavior change. The recommendation is to
forward this list to upstream for more thorough investigation:
* [https://cmake.org/cmake/help/latest/policy/CMP0054.html CMP0054]
`if("var" STREQUAL "check_value")` used to be equivalent with `if(var
STREQUAL "check_value")`.
== Dependencies ==
There are currently 776/2359 packages that dependent on `cmake` which
are affected, gathered and built using mass-pre-build in
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-4.0/ copr].
Not all build failures are due to CMake updates, and most of them
would be fixed by a bump of `cmake_minimum_required`.
== Contingency Plan ==
* Contingency mechanism: N/A (no deadline set)
* Contingency deadline: No deadline necessary yet
* Blocks release? No
== Documentation ==
* CMake 4.0 Release Notes: https://cmake.org/cmake/help/latest/release/4.0.html
* List of policies dropped:
https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html#unsupporte…
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/CMake_ninja_default
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-cmake-use-ninja-…
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 ==
Change the default generator used in the `%cmake` macro from `make` to
`ninja`. Affected projects are tracked in
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-ninja/ this copr
repo], please check if your packages are failing there.
== Owner ==
* Name: [[User:lecris| Cristian Le]]
* Email: fedora(a)lecris.me
== Detailed Description ==
`ninja` is generally regarded as a faster build backend/generator than
`make`, and recently CMake features support the `ninja` backend
better. Various packages already define and use the `ninja` backend
manually, and this change proposal would change the build backend to
all of the other packages that use the `%cmake` macro.
Indirect callers to `cmake` such as when part of python package, would
be unaffected and they could implement an equivalent change
independently.
=== Migration ===
{{admon/tip | Compatibility with fedora releases | Any proposed
changes here are compatible with any CMake versions and can be
included at any point and backported to any Fedora release.
<br>The corresponding
[https://src.fedoraproject.org/rpms/cmake/pull-request/51 cmake PR]
will not be merged until the affected packages are patched.
}}
* Make sure you do not use any `%make_install` and equivalent in the
spec file. Instead use the generator agnostic macros `%cmake_build`,
`%cmake_install`, etc.
* If you need to opt-out of the ninja generator add the following line
in the specfile before the `%cmake` execution
%global cmake_generator make
== Benefit to Fedora ==
* Faster build system
* Better out-of-the-box support for newer CMake features such as C++
module support
== Scope ==
* Proposal owners:
** Make the `ninja` build backend be the default
** Try to propose appropriate fixes as much as possible
** Investigate the edge-cases that are not covered in [[Migration]]
* Other developers:
** Adjust the spec file at least with the minimum quick fix. See [[Migration]].
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Affected packages would be FTBFS (in the tracked
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-ninja/ copr
repo]) and would require patching before the corresponding
[https://src.fedoraproject.org/rpms/cmake/pull-request/51 cmake PR]
can be merged.
== How To Test ==
A copr repo will be provided with these variables dropped. Use it to
try local builds, e.g. using:
copr mock-config lecris/cmake-drop_vars fedora-rawhide-x86_64
If the build is successful, that should be sufficient.
== Dependencies ==
There are currently 310/2359 packages affected gathered and built
using mass-pre-build in
[https://copr.fedorainfracloud.org/coprs/lecris/cmake-drop_vars/
copr], [https://copr.fedorainfracloud.org/coprs/lecris/cmake-ninja.checker/builds/
many of them] are previously FTBFS in rawhide.
== Contingency Plan ==
* Contingency mechanism: N/A (no deadline set)
* Contingency deadline: No deadline necessary yet
* Blocks release? No
== Documentation ==
* [https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake
CMake Packaging Guidelines]
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Fedora Linux 42 is now officially available!
Read the details in our Fedora Magazine article at:
* https://fedoramagazine.org/announcing-fedora-linux-42
or download installer images from:
* https://fedoraproject.org/
or, of course, simply upgrade your already-installed systems, which
shouldn't take much longer than ordering and consuming something which is
almost, but not quite, entirely unlike tea.
If you run into any trouble, or just have
questions, you can find help at:
* https://ask.fedoraproject.org/
NOTE: there's an important known issue with some of our Live media in this
release adding extra UEFI boot entries. We caught this too late to
reasonably pull things back. For details, see
* https://discussion.fedoraproject.org/t/148774
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader