KDB seems to work easier than KGDB over Hyper-V VM serial ports.
The same kernel command line parameters used to enable KGDB are used
to enable KDB too. All the KDB commands are enabled at compile time, but
the run time availability of these features can be restricted by using the
kdb.cmd_enable command line parameter.
Switching back and forth between KDB to KGDB/gdb mode is also supported
(when debugging a machine where KGDB was working before this change).
Co-authored-by: Daniel Mihai <dmihai@microsoft.com>
* kernel: Update mariner cert in kernel keyring
* kernel-hyperv: Update mariner cert in kernel keyring
* kernel-headers: Bump to match kernel release number
* kernel-signed: Bump to match kernel release
Signed-off-by: Chris Co <chrco@microsoft.com>
* Update to 5.15
* audit: update to 3.0.6
Current audit 3.0 version fails to build because linux/ipx.h header
is no longer part of 5.15 kernel source. audit 3.0.6 has a change to
handle this 5.15 difference.
Co-authored-by: Chris Co <chrco@microsoft.com>
Update kernel to 5.10.60.1. Apply patch for kernel to work with hyperv as in #1233. Remove cn from dracut add-drivers as in #1406. Address 24 CVEs. No kernel config changes were needed.
On certain poorly-behaving hardware, CONFIG_EFI_DISABLE_PCI_DMA can
cause the kernel to fail to boot. When this happens, the boot log
shows an EFI stub error where Exit boot services failed:
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
EFI stub: ERROR: Exit boot services failed.
EFI stub: ERROR: Failed to update FDT and exit boot services
To confirm if one is hitting this specific PCI busmastering issue, one
can add "efi=no_disable_early_pci_dma" to the kernel command line
and observe if the boot issue goes away.
Since this kernel package serves a wider array of hardware, some of
which do exhibit this boot failure, let's disable the config by default.
Signed-off-by: Chris Co <chrco@microsoft.com>
* 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>
* 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>
Update the kernel to 5.10.28.1.
- 5.10.28.1 addresses the following CVEs:
CVE-2020-27170, CVE-2020-27171, CVE-2021-28375, CVE-2021-28660,
CVE-2021-28950, CVE-2021-28951, CVE-2021-28952, CVE-2021-28971,
CVE-2021-28972, CVE-2021-29266, CVE-2021-28964, CVE-2020-35508,
CVE-2020-16120, CVE-2021-29264, CVE-2021-29265, CVE-2021-29646,
CVE-2021-29647, CVE-2021-29649, CVE-2021-29650, CVE-2021-30002
- update uname_r define
It is generally expected that users can run "dnf install
kernel-devel-$(uname -r)" to pull the proper kernel-devel package
associated with the currently running kernel. Currently "uname -r"
returns something like "5.10.28.1-rolling-lts-mariner-1.cm1". RPM
package naming has the following convention:
[name]-[version]-[release].[arch].rpm
where [version] and [release] cannot contain any dash characters.
Therefore it is impossible to name a corresponding kernel-devel RPM
to match kernel-devel-$(uname -r).
In 5.10.28.1, we changed the kernel Makefile's EXTRAVERSION value from
"EXTRAVERSION=.1-rolling-lts-mariner" to "EXTRAVERSION=.1", dropping
the extra "rolling-lts-mariner" from the uname. This allows the
"dnf install kernel-devel-$(uname -r)" to work as intended.
Signed-off-by: Chris Co <chrco@microsoft.com>
Add a few more F34 patches that are useful to carry.
Patches:
- 017: fix for passing the kernel command line
- 037, 052: updates the documentation and makes patch 166 apply cleanly
- 069: Fix for tsc problem
- 166: Prevent user from overwriting signed grub EFI binary when using
grub2-install
Signed-off-by: Chris Co <chrco@microsoft.com>
Update grub2 from 2.02 to 2.06-rc1 which handles BootHole v2. Additionally, we
drop all previous patches and rebaseline using a minimal number of patches
from FC34. These patches implement Secure Boot Handover protocol (needed
so the TPM Eventlog can be exposed to the kernel for TPM attestation scenarios)
and a few other nice-to-have fixes.
2.06 also introduces a new generation number based revocation mechanism known
as Secure Boot Advanced Targeting (SBAT) into the grub EFI binary. Components
that utilize the SHIM for secure boot will add an .sbat field into their binary's
PE-header, allowing the SHIM to check the component's sbat field against known
good component versions and allow for version-based revocation.
Signed-off-by: Chris Co <chrco@microsoft.com>
This PR has two changes:
Address kernel CVEs, fix kernel-signed file copy
Address CVE-2021-27365, CVE-2021-27364, CVE-2021-27363
kernel-signed %install step was not copying hidden files to the
buildroot directory (i.e., /boot/.vmlinuz-<uname_r>.hmac). So fix
the copy step.
Enable CONFIG_FANOTIFY_ACCESS_PERMISSIONS
This allows security products to block access to malicious files in real-time
Signed-off-by: Chris Co chrco@microsoft.com
* initial update kernel to 5.10.21.1
* add new CONFIG_KCMP
CONFIG_KCMP was introduced between our last kernel version and
this one. CONFIG_KCMP is selected (=y) by CONFIG_DRM and
CONFIG_CHECKPOINT_RESTORE
* Add virtio drivers to be added into initrd
Adding these drivers into the initrd allows us to boot offline-created
images on virtio-based machines (i.e., cloud-hypervisor VMs)
* kernel: Address CVEs
"Nopatch" the following CVEs. They are fixed in 5.10.21.1
- CVE-2021-26930
- CVE-2020-35499
- CVE-2021-26931
- CVE-2021-26932
* Remove CONFIG_USB_LGM_PHY from aarch64 config
New kernel version only exposes this config if building for X86.
Signed-off-by: Chris Co <chrco@microsoft.com>
* kernel: enable kernel lockdown lsm
* kernel-hyperv: enable kernel lockdown lsm
* kernel-signed: Use uname_r macro everywhere
There was a build break due to an incorrect name used
for vmlinuz in SOURCE1.
The new 5.10 kernel source introduced a new versioning
scheme when built. EXTRAVERSION will always contain
"-rolling-lts-mariner".
In kernel.spec, the vmlinuz we output has the name:
vmlinuz--rolling-lts-mariner-, which
is constructed using vmlinuz-%{uname_r}
So to fix, use vmlinuz-%{uname_r} in the kernel-signed
specs as well.
* add more lockdown configs
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y enables the lockdown lsm
very early prior to the security subsystem's initialization.
Still subject to kernel boot parameters.
CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y no lockdown functionality
enabled by default, but can be enabled via kernel commandline or
/sys/kernel/security/lockdown
General distros should set lockdown integrity mode, while special
purpose distros should set lockdown confidentiality mode. These
can be set in the kernel command line
Signed-off-by: Chris Co <chrco@microsoft.com>
Move to the new CBL-Mariner kernel source location and use the latest
5.10.13.1 version.
As part of the upgrade to 5.10.13.1, we can remove some out-of-tree
patches since these patches have been merged into upstream.
Additionally, we need to account for the new location of module.lds
for aarch64 builds. The aarch64 module.lds is no longer checked in
as part of the source tree. See this upstream commit for more details:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=596b0474d3d9b1242eab713f84d8873f9887d980
Turn off CONFIG_GCC_PLUGIN_RANDSTRUCT protection. This struct
randomization is causing difficulty in parsing vmcore files.
Enable upstream smartpqi driver by default
Signed-off-by: Chris Co <chrco@microsoft.com>
* Add i.MX8mq-evk board support
Modify the kernel configs to include the needed drivers as well as voltage regulators.
Add the dtb to the kernel spec as a subpackage by arch type
Update the kernel files to match spec version number
- Update kernel-headers, kernel, kernel-hyperv, and hyperv-daemons specs to use 5.4.83
- Refresh version numbers for kernel-signed- specs
- Update toolchain to use 5.4.83 source when building kernel headers
- Address CVE-2020-14351, CVE-2020-14381, CVE-2020-25656, CVE-2020-25704,
CVE-2020-29534, CVE-2020-29660, CVE-2020-29661
- Update cgmanifest's download URLs to point to 5.4.83 source location
Dan Mihai