Zram needs CONFIG_ZRAM_WRITEBACK in order for writeback configuration
to work. Since there is even a NixOS option (zramSwap.writebackDevice)
for configuring writeback, it should be enabled.
Support for IR remotes was originally introduced in NixOS in 2013 with
[1]. This worked fine until 2018 with the release of Linux 4.16 which
contained [2], which removed the default-enable on the IR decoders.
This means that kernels since then build with RC_DEVICES enabled, but
RC_DECODERS disabled:
```
CONFIG_RC_DEVICES=y
```
This breaks IR remote support and also leads to the following error on
every bootup when such a device is present as devices have a default
keymap which uses a protocols decoder, but these decoders are not
available:
```
rc_core: Loaded IR protocol module ir-rc6-decoder, but protocol rc-6 still not available
```
Fix this by also enabling RC_DECODERS in the kernel configuration.
[1] b7ccfc258a
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22756ae7319b0afc2a80fbdec365a6976a1ad350
These are required to debug kernel modules. Since we're now able to
do that, there's another reason besides BTF to enable DEBUG_INFO, so
I've done that for pre-BTF kernel modules as well here.
For GDB to get configured correctly, vmlinux-gdb.py has to be two
directories up from scripts/gdb, and vmlinux has to be next to
vmlinux-gdb.py. The least invasive way to satisfy these constraints
is to make vmlinux a symlink, which GDB will resolve before looking
for vmlinux-gdb.py.
Tested both ways of getting the scripts into GDB that I know of:
gdb /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/vmlinux \
-iex 'add-auto-load-safe-path /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/lib/modules/6.1.19/build/vmlinux-gdb.py' \
-ex 'lx-version' \
-ex 'q'
gdb /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/vmlinux \
-ex 'source /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/lib/modules/6.1.19/build/vmlinux-gdb.py' \
-ex 'lx-version' \
-ex 'q'
Also tested that the strip changes don't result in meaningful output
size changes (there's some small variation due to BTF data not always
coming out the same size, which is unrelated), and built every kernel
I can on x86_64 to make sure I'm not relying on build system behaviour
specific to newer kernels.
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
