Aluciani:new_config_file (teest under qemu over 6.1.8 kernel bump branch)

[tlaurion]

Superseeds #1816 with documentation in commit logs from "Oct 20, 2024" at https://github.com/linuxboot/heads/pull/1817/commits

@aluciani: please review commit logs and challenge directly as comments under nv41 shared linux config file with ns50 at https://github.com/linuxboot/heads/pull/1817/files/0ef67e1e87d31d59c9886b75c6d5daaa42bd626e#diff-782b88c1e0e03988fb8336bd99c65310869be9f3c1e3a88a1be57bcd5ab7c4e8

---

Putting as draft. Here too: not ready for merge. Commitss could be cherry-picked on top of #1803 from which ithis PR is based on top of.

[tlaurion]

@aluciani for the sake of this PR changes, I think reviewing and commenting changes directly under config/linux-nitropad-x.config as comments would facilitate progress on this PR.

[aluciani]

Enables core scheduler to enhanced process scheduling
KSPP : Make scheduler aware of SMT Cores. Program needs to opt-in to using this feature with prctl(PR_SCHED_CORE).

[aluciani]

Increases ASLR entropy for mmap allocations, improving security against memory-based attacks.
From 28 to 32

[aluciani]

Merging slabs can potentially lead to memory reuse vulnerabilities if a freed slab is reused without proper sanitization.
KSPP : Make cross-slab heap attacks not as trivial when object sizes are the same. (Same as slab_nomerge boot param.)

[aluciani]

Randomizes the order of the freelist in the slab allocator.
KSPP : Randomize allocator freelists, harden metadata.

[aluciani]

Harden the slab allocator’s freelist to protect against heap-based attacks.
KSPP : Randomize allocator freelists, harden metadata.

[aluciani]

Adds protections against buffer overflows.
KSPP : Check for memory copies that might overflow a structure in str*() and mem*() functions both at build-time and run-time.

[aluciani]

Initializes memory to a default value upon allocation.
Ensures that newly allocated memory does not contain residual data from previous allocations.
KSPP : Wipe slab and page allocations (since v5.3)

[aluciani]

Initializes memory to a default value upon allocation.
Prevents Information Leakage.
KSPP : Wipe slab and page allocations (since v5.3), The init_on_free is only needed if there is concern about minimizing stale data lifetime.

[aluciani]

Enables a kernel feature for detecting use-after-free and other memory safety issues.
KSPP : Enable sampling-based overflow detection (since v5.12). This is similar to KASAN coverage, but with almost zero runtime overhead.

[aluciani]

Sets the sampling interval for KFENCE to 100, determining how frequently memory allocations are checked.
Recommendation of KSPP

[aluciani]

We might also want to reduce the CONFIG_BLK_DEV_LOOP_MIN_COUNT from 8 to 2.
Each block is around 256 (up to 512) bytes (please correct me if I'm wrong), so
8 * 256 = 2048 bytes
2 * 256 = 512 bytes
Worth the space.

I wanted to reduce the value of CONFIG_NR_CPUS for the same reason, each supported CPU adds 8KB, so :
For 32 CPUs: 32 CPUs×8192 bytes/CPU =262,144 bytes (≈256KB)
For 24 CPUs: 24 CPUs×8192  bytes/CPU =196,608 bytes (≈192KB)
Memory Savings:
262,144bytes−196,608bytes=65,536bytes(≈64KB)

But I understand that it will be a pain to update every linux configuration for every card every time.

[aluciani]

The kernel-hardening-checker also talks about CFI, I think it would also be a plus to have it, but I think it would slow head down too much.
CONFIG_CFI_AUTO_DEFAULT

[aluciani]

@aluciani this is nice exercise. Wondering if https://github.com/a13xp0p0v/kernel-hardening-checker should be added under nix docker image and some self-test should be added in CI in long term to make those checks automatic and warn of security regressions, somehow.

#1816 (comment)

The tool is good and complete. But the problem is that it has a lot of checks, most of which don't apply here.The ones suggested here are in the minority.
I don't know if integrating it into nix is a good idea. Or it could be for a limited number of configurations.

[aluciani]

Seccomp, Stack Leak Protection, and Strict Memory Access could also be enable with thoses parameters :

• CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER to enhance security by enabling syscall filtering.
• Switch to CONFIG_EFI_DISABLE_PCI_DMA for better PCI DMA security in EFI environments.
• Switch IOMMU default behavior to strict mode with CONFIG_IOMMU_DEFAULT_DMA_STRICT to enforce stricter DMA rules.
• CONFIG_SECURITY_DMESG_RESTRICT to limit access to kernel messages and reduce attack surface.
• CONFIG_STRICT_DEVMEM and CONFIG_IO_STRICT_DEVMEM to restrict access to /dev/mem and prevent unintended access to hardware memory.

[tlaurion]

A quick reminder that Heads is a controlled flow environment, GUI based where user input are related to secret provisioning.

Other areas criticized for Heads are filesystem parsing/mounting where not much more can be done then print_tree sanitization in code right now, where luks/ext3/ext4/exfat is a bit out of reach of further sanitization as of now. Also noted that Heads parses syslinux/grub configs, where some additional sanitization could happen, with opened issues.

I'm open to further kernel hardening, but Heads use case of kernel needs to be understood. Across platforms, different uses of sysfs and devmem happens, where "ultimate lockdown" is currently optional : that is Authenticated wall guarded recovery shell access + usb boot with USB Security dongle (something you have and something you know: its GPG User PIN to detach sign + verify detached signature with public key fused inside of Heads measured boot public key).

We could tune kernel further more, but corner case impact will be discovered only with extensive testing, which is to be dodged for ease of maintainability and generalization of kernel config across all boards.

@aluciani what additional prevention is thought to be added by hardening further more the kernel with your past comment?

[tlaurion]

Seccomp, Stack Leak Protection, and Strict Memory Access could also be enable with thoses parameters :

• CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER to enhance security by enabling syscall filtering.

I don't see why not, but might cause problems in corner cases.

• Switch to CONFIG_EFI_DISABLE_PCI_DMA for better PCI DMA security in EFI environments.

I see possible problems, would need extensive testing (coreboot fb -> efifb basic 2d fb prior of final OS doing drm+3d modules loading and own graphic card on its own with kexec passing coreboot fb to final OS)

• Switch IOMMU default behavior to strict mode with CONFIG_IOMMU_DEFAULT_DMA_STRICT to enforce stricter DMA rules.

Same as above for same reasoning

• CONFIG_SECURITY_DMESG_RESTRICT to limit access to kernel messages and reduce attack surface.

I don't see interest, Heads is single root user where dmesg is used to even dump debug info to be outputted under /tmp/debug.log if put in TRACE+DEBUG mode through config settings to understand what Heads does. No go.

• CONFIG_STRICT_DEVMEM and CONFIG_IO_STRICT_DEVMEM to restrict access to /dev/mem and prevent unintended access to hardware memory.

I see problems here as well.