Enables the following kernel config options for AMD CPUs on x86_64:
- `CRYPTO_DEV_CCP`: Enables offloading of crypto operations to AMD's
Cryptographic Coprocessor (CCP). Also required by `KVM_AMD_SEV`.
- `AMD_MEM_ENCRYPT`: Enables support for Secure Memory Encryption (SME).
Please note that `AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT` is not enabled;
yet, you you can enable memory encryption by passing `mem_encrypt=on`
as a kernal command line option.
- `KVM_AMD_SEV`: Enables launching Encrypted VMs (SEV) and Secure VMs
with Encrypted State (SEV-ES).
- `SEV_GUEST`: Enables support for AMD Secure Encrypted Virtualization
with Secure Nested Paging (SEV-SNP). Built as module.
Enabling these options is in line with other distros, e.g., Debian,
Fedora or Arch Linux.
CONFIG_NO_HZ_FULL=y should be set to enable the `nohz_full=` and
`rcu_nocbs=` options. These carry no additional performance penalty
compared to CONFIG_NO_HZ_IDLE and behaves like it by default,
but allows disabling the tick interrupts on cores for power or
performance reasons.
[Debian][1] also applied the change to all their kernels.
Like the Kernel says: "If you're a distro say Y."
[1]: f6aad27f05
PERSISTENT_KEYRINGS provides a register of persistent per-UID keyrings, useful for encrypting storage pools in stratis.
KEYS_REQUEST_CACHE enable temporary caching of the last request_key() result.
This currently gets enabled as generate-config.pl will enable all the
drivers below it as modules.
Is “not set” in [Arch][1], [Debian][2], [Fedora][3]. See also [summary
of setting from various distros in April 2020][4].
Recommended disabled by [CLIP OS][5] and per current [Kernel config
description][6]:
> bool "Enable legacy drivers (DANGEROUS)"
> Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
> APIs to user-space, which can be used to circumvent access
> restrictions and other security measures. For backwards compatibility
> those drivers are still available, but their use is highly
> inadvisable and might harm your system.
>
> You are recommended to use the safe modeset-only drivers instead, and
> perform 3D emulation in user-space.
>
> Unless you have strong reasons to go rogue, say "N".
Also disable NOUVEAU_LEGACY_CTX_SUPPORT, as this does `select
DRM_LEGACY`. Per Kernel config docs:
>There was a version of the nouveau DDX that relied on legacy
> ctx ioctls not erroring out. But that was back in time a long
> ways, so offer a way to disable it now. For uapi compat with
> old nouveau ddx this should be on by default, but modern distros
> should consider turning it off.
and the [commit][7]:
> These driver functions contain several bugs and security holes. This
> change makes these functions optional can be turned on by a setting,
> they are turned off by default for modeset driver with the exception of
> the nouvea driver that may require them with an old version of libdrm.
Referenced earlier commit elaborates that
> libdrm_nouveau before 2.4.33 used contexts
Since nixpkgs here has a much newer version (2.4.33 is from March 2012),
should not be a concern.
NOUVEAU_LEGACY_CTX_SUPPORT is also “not set” in the linked Arch, Debian,
& Fedora configs.
[1]: 66d72ee54a/trunk/config (L6637)
[2]: 07731f5956/debian/config/config (L713)
[3]: https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel-x86_64-fedora.config#_1528
[4]: https://github.com/a13xp0p0v/kconfig-hardened-check/issues/38#issuecomment-608639217
[5]: https://docs.clip-os.org/clipos/kernel.html#configuration
[6]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/Kconfig#n421
[7]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b30a43ac7132cdda833ac4b13dd1ebd35ace14b7
Right now it looks like the BTFs are not reproducible between different builds
of the same kernel, and the kernel will refuse to load modules if the BTF
doesn't match. This can cause some interesting side effects when Nix
uses different substituters for different parts of the kernel.
This is far from ideal, and we _really_ should figure out how to actually
make the BTF building consistently reproducible, but that seems more
complicated, so maybe we should do this to get affected systems booting.
See also: https://lore.kernel.org/bpf/YfK18x%2FXrYL4Vw8o@syu-laptop/ ,
where the openSUSE people ran into similar issues.
This reverts commit 79e05fb16b.
broken 32bit BTF builds got fixed in #175467 by switching libbpf from
libelf to elfutils, as a side-product of the upgrade, so we don't need
this anymore.
Linux's aarch64 defconfig has been updated in 5.13 to enable "reduced"
debug infos (upstream commit ed938a4bfc58 ("arm64: defconfig: Use
DEBUG_INFO_REDUCED"), but that commits locks DEBUG_INFO_BTF as noticed
in #175467
This disables it back which should fix bpftrace usage of BTF not working
on newer kernels.
gcc update frequently breaks most recent kernel releases due to blanket -Werror
flag. Let's avoid -Werror in a default build to ease kernel and gcc maintenance.
Very confusingly, the `isPowerPC` predicate in
`lib/systems/inspect.nix` does *not* match `powerpc64le`!
This is because `isPowerPC` is defined as
isPowerPC = { cpu = cpuTypes.powerpc; };
Where `cpuTypes.powerpc` is:
{ bits = 32; significantByte = bigEndian; family = "power"; };
This means that the `isPowerPC` predicate actually only matches the
subset of machines marketed under this name which happen to be 32-bit
and running in big-endian mode which is equivalent to:
with stdenv.hostPlatform; isPower && isBigEndian && is32bit
This seems like a sharp edge that people could easily cut themselves
on. In fact, that has already happened: in
`linux/kernel/common-config.nix` there is a test which will always
fail:
(stdenv.hostPlatform.isPowerPC && stdenv.hostPlatform.is64bit)
A more subtle case of the strict isPowerPC being used instead of the
moreg general isPower accidentally are the GHC expressions:
Update pkgs/development/compilers/ghc/8.10.7.nix
Update pkgs/development/compilers/ghc/8.8.4.nix
Update pkgs/development/compilers/ghc/9.2.2.nix
Update pkgs/development/compilers/ghc/9.0.2.nix
Update pkgs/development/compilers/ghc/head.nix
Since the remaining legitimate use sites of isPowerPC are so few, remove
the isPowerPC predicate completely. The alternative expression above is
noted in the release notes as an alternative.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
> Some bootloaders can provide entropy to increase the kernel's initial device randomness.
This allows, for example, EFI to provide 64 bytes. In general my opinion is an attacker
who can manipulate the random seed sufficiently to cause problems likely has other,
more direct approaches at their disposal as well.
This broke older kernels in PR #155613 (commit 8aae7afa3e).
I only checked the kernel versions that we maintain,
so (>= 4.14) might be an imprecise condition.
Enable for SND_SOC_INTEL_SOUNDWIRE_SOF_MACH kernel module. This is used
on some 10/11th gen Intel laptops such as the XPS 17 97[00|10]
Enable SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES as well - this is required dep
Enable Intel Software Guard eXtensions (SGX) on x86 when using Linux
5.11.0 or later. Also enable KVM guests to create SGX enclaves if
running Linux 5.13.0 or later.
> The MediaTek protocol support enables firmware download support and chip initialization for MediaTek Bluetooth USB controllers.
Necessary to make Bluetooth work on some MediaTek controllers.
Core scheduling is a recent innovation in newer kernels to help run
certain untrusted compute workloads more safely in the face of
vulnerabilities like Spectre. In short: it lets processes assign a
unique "cookie" to some group of processes to indicate they are allowed
to be scheduled together on the same SMT-capable core. This helps
mitigate attacks that rely on observing usage of CPU execution units by
cohabitated threads.
Some extra details are available via Linux Weekly News:
"Core scheduling lands in 5.14", https://lwn.net/Articles/861251/
Signed-off-by: Austin Seipp <aseipp@pobox.com>