* Update Mariner Core base image keeping dnf wget vim as optional packages
* Add core-packages to validate-cg-manifest ignore list
* Add license verfied to core-packages spec
* rebase on rlmenge/rlmenge/main-rebase/kernel-5.15
* successful local build kernel-rt 5.15.2.1
* fix kernel/config mismatch
* add utility packages for rt development
* build rt packages
* modify rt-tests source to point at proper location
* update rt-tests signature
* dashroll kernel-rt to match kernel
* fix issues with old certs being used in kernel-rt
* update kernel-rt source
* bring in python-ethtool
* fix python-ethtool signature
* remove redundant SPECS-EXTENDED folders for specs moved into SPECS
* cleanup duplicates in -EXTENDED, license.json and verify licenses
* conform to license checker
* more license debugging, downgrade pygobject2 since it was only needed for the (since removed) gui portions of tuned
* rerun license map script
* finish rebase
* switch off of temporary local manifests
* fix signature name for python-ethtool, add iso json for rt
* fix python-ethtool signature mess
* bump kernel-rt release to match kernel
* readd newline to manifests
* apply changes from PR #2075 onto kernel-rt
* fix changelog typo
* grub-signed: Commonize on one spec
Use macros to swap spec contents based on build architecture. We will
still create an SRPM per arch, each with a unique name, so there is no
risk of SRPM name collision.
* grub-signed: Define new grub2-efi-binary subpackage
New subpackage will contain the signed grubx64.efi/grubaa64.efi binary.
This package name is identical to the unsigned version and we will
prefer to use this signed version if built.
* grub-signed: rename files
* grub2: bump spec version to match signed version
* Update github action checks
CG manifest, license file, and spec entanglement checks are failing
due to the grub-efi-binary-signed naming change. Update the checks to
account for the new name.
* grub2-signed: rename source0 to match subpackage
Source0 previous pointed to grub2-efi-unsigned rpm which technically
can work but it would be better to use the grub2-efi-binary package
instead because grub2-efi-binary package is ultimately the package we
will be replacing. We can also perform checks to make sure the output
rpm matches the inputs, modulo the signed binary.
Signed-off-by: Chris Co <chrco@microsoft.com>
* shim: Introduce shim package
Shim package contains a signed shim bootloader which is signed with the
Microsoft UEFI CA cert to allow it to load on many different platforms
that support UEFI Secure boot. If UEFI Secure Boot is enabled, this shim
binary will verify that next stage bootloaders (i.e., grub and kernel)
are signed with the CBL-Mariner secure boot key.
* shim: add extra versioning info to source0
Renamed Source0 tarball naming to prevent future tarball naming
collisions.
* CI: ignore shim during cgmanifest check
shim package's Source0 is a signed binary created by us.
* licenses-map: Add shim to table
* shim: prefer install over cp
* licenses: Add shim to data file
Fixes error thrown by spec license checker
* shim: Add comment explaining why only x86_64 shim
Signed-off-by: Chris Co <chrco@microsoft.com>
* kernel-signed: define a new kernel subpackage
This spec purpose is to take an input kernel rpm and input secure-boot-signed
kernel binary from the same build and generate a new "kernel" rpm with the
signed kernel binary + all of the other original kernel files, triggers,
scriptlets, requires, provides, etc.
We need to ensure the kernel modules and kernel binary used are from the exact
same build because at build time the kernel modules are signed with an
ephemeral key that the kernel enrolls in its keyring. We enforce kernel
module signature checking when we enable security features like kernel
lockdown so our kernel can only load those specific kernel modules at runtime.
Additionally, to complete the UEFI Secure Boot chain, we must PE-sign the
kernel binary. Ideally we would enable secure-boot signing tools like pesign
or sbsign to be callable from inside the rpmbuild environment, that way we can
secure-boot sign the kernel binary during the kernel's rpmbuild. It is best
practice to sign as soon as possible. However there are issues getting that
secure boot signing infrastructure in place today. Hence we sign the
resulting kernel binary and "repackage" the kernel RPM (something rpm itself
actively tries to make sure you never do...generally for good reasons).
To achive this repackaging, this spec creates a new subpackage named
"kernel". To retain all of the initial kernel package behaviors, we make sure
the subpackage has the same requires, provides, triggers, post steps, and
files as the original kernel package.
This specific repackaging implementation leaves room for us to enable the
more ideal secure-boot signing flow in the future without introducing any
sort of breaking change or new packaging. Users still install a "kernel"
package like they normally would.
Maintenance Notes:
- This spec's "version" and "release" must reflect the unsigned version that
was signed. An important consequence is that when making a change to this
spec or the normal kernel spec, the other spec's version version/release must
be increased to keep the two versions consistent.
- Make sure the kernel subpackage's Requires, Provides, triggers, post/postun
scriptlets, and files match the normal kernel spec's. The kernel subpackage
should contain the same content as the input kernel package but replace the
kernel binary with our signed kernel binary. Since all the requires, provides,
etc are the same, this new kernel package can be a direct replacement for the
normal kernel package and RPM will resolve packages with kernel dependencies
correctly.
To populate the input sources:
1. Build the unsigned packages as normal
2. Sign the desired binary
3. Place the unsigned package and signed binary in this spec's folder
4. Build this spec
* kernel-signed: refactor into one common spec file
The only differences between kernel-signed-x86_64 and
kernel-signed-aarch64 spec files were primarily the architecture
type in the spec name and input Source0 rpm. We can use a macro to set
these and reduce down to one spec file
* Update checks to consider kernel-signed
* kernel-hyperv: match release number
Ideally we keep kernel-headers version/release in sync with kernel and
kernel-hyperv package version/release. This allows the user to install
kernel-headers on any Mariner system by using
dnf install kernel-headers-$(uname -r)
Signed-off-by: Chris Co <chrco@microsoft.com>
Add a custom installkernel script to easily install the Linux kernel
onto a running Mariner system. This script will get called automatically
by the Linux kernel's "make install" command.
Signed-off-by: Chris Co <chrco@microsoft.com>
* diskutils: Add partprobe after partition creation
There can be a timing issue where partition creation finishes but the
devtmpfs files are not populated in time for partition initialization.
So to deal with this, we call partprobe here to query and flush the
partition table information, which should enforce that the devtmpfs
files are created when partprobe returns control.
* diskutils: invoke partprobe with flock
Added flock because "partprobe -s" apparently doesn't always block.
flock is part of the util-linux package and helps to synchronize access
with other cooperating processes. The important part is it will block
if the fd is busy, and then execute the command. Adding a 5 second timeout
to prevent us from possibly waiting forever.
* diskutils: Update timeout variable name
* diskutils: clarify debug log message
* Add parted to documentation and quickstart runner
Signed-off-by: Chris Co <chrco@microsoft.com>
Pawel Winogrodzki
chalamalasetty
Cameron E Baird
Thomas Crain
Max Brodeur-Urbas
Andrew Phelps
jslobodzian
Christopher Co
Mateusz Malisz
Daniel McIlvaney