To help debug scsi errors, enable the scsi logging facility. By default,
perf will not be impacted. And this facility allows the user to enable
scsi logging at runtime.
Note: Size of kernel will increase with this change
Signed-off-by: Chris Co <chrco@microsoft.com>
Certain applications we'd like to use are throwing errors indicating
that 32 bit get_time syscalls aren't available, returning:
-1 ENOSYS (Function not implemented)
To resolve this, enable 32 bit time_t support in the kernel.
Signed-off-by: Chris Co <chrco@microsoft.com>
* first commit of MarinerFedRamp2.0
* first commit for FedRAMP2.0
* patched all the asc cases in source code
* address Daniel's review comments for Mariner 2.0 FedRAMP
* move dsiabling ICMP redirect from source to packer
* Update SPECS/shadow-utils/shadow-utils.spec
Co-authored-by: Christopher Co <35273088+christopherco@users.noreply.github.com>
* Update SPECS/fedramp/fedramp.spec
Co-authored-by: Christopher Co <35273088+christopherco@users.noreply.github.com>
* address the comments in 2nd round reviews
* add asc.spec to replace fedramp.spec
* delete fedramp spec
* fix typo and remove changes for system-password
* update manifest file
* remove some unnecessary changes
* add empty line at end
* update to pass PR check
* address 1st round review comments
* update changelog for license
* address review comments
* remove ssh access
Co-authored-by: rmhsawyer <mingheren@gmail.com>
Co-authored-by: Christopher Co <35273088+christopherco@users.noreply.github.com>
* Kernel upgrade to 5.15.60.1 version
* move kernel to 5.15.60.2 source to fix arm builds
* Clean up changelog; add nopatches for CVE-2022-36879, CVE-2022-36946, CVE-2022-2503, CVE-2022-1973
Co-authored-by: CBL-Mariner Servicing Account <cblmargh@microsoft.com>
* staging for now
* update grub2
* add grub pxe binary
* fix mistake in spec
* revert unnecessary changes
* add subpackage and update binary name
* update changes
* Update SPECS-SIGNED/grub2-efi-binary-signed/grub2-efi-binary-signed.spec
Co-authored-by: Christopher Co <35273088+christopherco@users.noreply.github.com>
Co-authored-by: Henry Li <lihl@microsoft.com>
Co-authored-by: Christopher Co <35273088+christopherco@users.noreply.github.com>
FTRACE_SYSCALLS was removed in a previous commit.
Sadly, this option is needed by eBPF CO-RE tools which use syscall tracepoints
(sys_enter_* and sys_exec_*).
Without this option, tools like iovisor/bcc/libbpf-tools/execsnoop cannot work
on CBL Mariner.
Also, some standard eBPF tools needs kernel headers to be available, hence
IKHEADERS was set as a module.
Without this option, tools like iovisor/bcc/tools/biolatency.py cannot work.
Fixes: 344c087e52 ("kernel configs to bring down boot time for initrd")
Signed-off-by: Francis Laniel <flaniel@linux.microsoft.com>
* Nopatch CVE-2020-35501
* Kernel update script --> 5.15.41.1
* correct hashes
* correct kernel-rt signature; don't auto update kernel-rt (we need to check for a patch-version)
* re-fix sig
* Address more cves
* fix kernel-rt cgmanifest entry
* fix dockerfile and update_kernel script tag
* remove tag errors in cgman
* use nifty new cve tool to generate more accurate nopatch
* fix console, cdrom, mouse, kexec aarch64 config
* Bump up release number
* Fix aarch64 config according to build
* Bump up release in kernel-header
* Update release in kernel-signed, add kernel option for initcall_blacklist
* Add config for crash-on-demand
* Fix order in pkggen_core
* update kernel to 5.15.34.1, clean up nopatches in kernel.spec, address CVEs
* bump kernel-rt config version
* add missed kernel-rt patch
* fix naming convention for kernel source tar to match that used in LSG
* fix toolchain container kernel source link
* correct toolchain kernel source hash
* fix signatures to be correct version of kernel source
* switch to cm2
* fix config hash kernel-rt
* fix usbip
* stop packaging tar creation script in usbip; add update_kernel.sh
* fix usbip again
* nopatch CVE-2022-29156
* clean up update_kernel.sh
* fix kernel debug symbol issue
* update kernel-headers
* update hyperv-daemons and kernel-rt
* fix typo in specs
* remove xerces-c-devel BR from kernel
* exclude debug folder from main kernel package. fix bogus date in changelog
* remove aarch64 exclude workaround. use /usr/lib/debug
* [main] Enable NO_IOMMU kernel flag.
In order to support high data throughput for network connections, user-mode
drivers require direct access to the underlying devices. Such access can be
managed/protected by the IOMMU controller if it is present in the hardware.
For VMs, we may not have IOMMU exposed by the hypervisor. So we must provide
a way for the VFIO module to say that there is no IOMMU but still use VFIO
to keep the software stack the same.
The Mariner kernel today is compiled such that IOMMU is always required for
such user-mode drivers to work. This is a problem for virtual machines where
such requirement cannot be met.
This fix changes the kernel NO_IOMMU compile option such that it is possible
for the root user to choose whether to require IOMMU or not based on their
needs without recompiling the kernel.
The default is that IOMMU is required.
The root user must explicitly disable the IOMMU requirement with the following
command:
/sbin/modprobe vfio enable_unsafe_noiommu_mode=Y
* Enable NO_IOMMU: update version of kernel related spec files.
* Enable NO_IOMMU: update toolkit references.
* Enable NO_IOMMU: update pkggen references.
* Update kernel signature file after merge with main.
* [1.0] shim: update shim bootloader (#2157)
* shim: update key used
Our current keys have a 1 year expiration time, and it will expire
shortly. Update the key to one that will expire in 10/13/22. Ultimately
we plan to move to a longer lived CA cert once that is made available.
* shim: Add critical patches
* shim: Update to new signed shim bootloader binary
New shim bootloader contains the renewed Mariner Secure Boot Production
key embedded inside. And this shim binary itself is signed with the MS
UEFI CA.
* grub: bump release number to force re-signing
In order to not regress current users of the grub2-2.06~rc1-7 package,
bump release number which will cause the newer grubx64.efi inside the
grub2-efi-binary-2.06~rc1-8 package to be signed with the updated secure
boot key that matches with the one embedded in the 15.4-2 shim binary.
* License verified
Signed-off-by: Chris Co <chrco@microsoft.com>
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
* Enable arm64 hyperv and SoCs support for CBL-Mariner
* Update kernel config for Arm64 arch
* Update kernel configs for arm64 arch
* Enable arm64 hyperv and SoCs support for CBL-Mariner
Co-authored-by: schalam <schalam@microsoft.com>
Update kernel source to 5.4.72. New kernel source contains fixes for many kernel CVEs flagged by our tooling so address the CVEs. As part of this update, also add the kernel COPYING file to the packages missing the license file.
* Add IMA feature to the kernel, add config for it
- Add IMA measurement configs to the x86_64, and aarch64 kernel configs (IMA_APPRAISE currently disabled).
- Add KernelCommandLine config field to control IMA, and allow additional configs to be passed.
Signed-off-by: Daniel McIlvaney <damcilva@microsoft.com>
Co-authored-by: Christopher Co <christopher.co@microsoft.com>
* Add kernel config checks
Automatically check if the kernel configs have any inconsistencies
during the SPEC build for both kernel and kernel-hyperv
* Address feedback
* kernel-signed-x64: Add missing requires
The %post step fails because /sbin/depmod is not present. depmod
is supplied by the kmod package.
This error manifested as a hyper-v boot hang where the image is
stuck infinitely waiting for the rootfs to mount. Since depmod was
never run during kernel installation, the module database is stale. Then when the initramfs regeneration occurs, certain modules (i.e. hv_storvsc)
are not available for dracut to include into the initrd.
Bump release number
* kernel-signed-aarch64: Add missing requires
The %post step fails because /sbin/depmod is not present. depmod
is supplied by the kmod package.
This error manifested as a hyper-v boot hang where the image is
stuck infinitely waiting for the rootfs to mount. Since depmod was
never run during kernel installation, the module database is stale. Then when the initramfs regeneration occurs, certain modules (i.e. hv_storvsc)
are not available for dracut to include into the initrd.
Bump release number
* kernel: Bump release
* kernel: clean up lingering invalid aarch64 configs
* kernel: Fix bogus date rpmlint message
As part of enabling the UEFI Secure Boot chain, the kernel binary must
be signed with our distro key.
At the moment, the signing infrastructure isn't quite ready to perform
inline signing during package build. So to work around this, we
introduced the kernel-signed-<arch> packages. The purpose of these
packages is to supply a way for signed versions of the kernel binary
and the associated kernel modules to land on the end-user's
filesystem.
As part of enabling UEFI Secure Boot, the grub2 EFI binary must be
signed with our distro key.
At the moment, the signing infrastructure isn't quite ready to perform
inline signing during package build. So to work around this, we
introduced the grub2-efi-binary-signed-<arch> packages. The purpose
of these packages is to supply a way for signed versions of the
grub efi binary to land on the end-user's filesystem.
CBL-Mariner-Bot