NetBSD <-> Linux kernel, hardening options, mounting fat32/ntfs USB

gaspachos78

Whats up, guys. Hows it going? Well, 2 questions that I have.
There are a lot of so called Linux hardening guides.
And when I want to harden my Linux kernel I do in my boot config
something like this:

1) lockdown=confidentiality

The kernel lockdown LSM can eliminate many methods
that user space code could abuse to escalate to kernel
privileges and extract sensitive information. This LSM
is necessary to implement a clear security boundary
between user space and the kernel.

2) intel_iommu=on, or
3) amd_iommu=on

this fights against DMA attacks

4) efi=disable_early_pci_dma

This option fixes a hole in the above IOMMU by disabling
the busmaster bit on all PCI bridges during very early boot.

5) init_on_alloc=1
6) init_on_free=1

This enables zeroing of memory during allocation and free
time which can help mitigate use-after-free vulnerabilities
and erase sensitive information in memory.

7) page_alloc.shuffle=1

This option randomizes page allocator freelists, improving
security by making page allocations less predictable. This
also improves performance.

8) ...
9) ...

In fact, there are hundreds of such kernel boot parameters.
Could some of you write NetBSDs analogies of 1),2),3),4),5),6),7),
that i wrote above? I mean, how can I make "efi=disable_early_pci_dma"
in NetBSD? What's the way to turn on "amd_iommu=on" in NetBSD?
You got the idea, right?

And the second question is: let's say one is having USB stick
with fat32 (or ntfs) file systems. How does one safely mount fat32 and ntfs
usb drives under NetBSD? Could some of you write roadmap (commands):
what should I do and which binary packets should I install in my fresh NetBSD
system to be able to mount and work with fat32 and ntfs USB drives.

Many thanks.

nia

We like having such options enabled by default (unless there's a severe performance or usability penalty), otherwise there's very little point to having them. If you want to try some non-default kernel hardening maybe look into GENERIC_KASLR and Prekern. You can also raise the kern.securelevel in /etc/sysctl.conf, see secmodel_securelevel(9) for a list of full effects (they include not being able to load modules post-boot).

You don't need to install any packages to mount fat32. mount_msdos should handle them fine. Usually in the context of an MBR disklabel FAT32 partitons are assigned e, so usually USB FAT32 partitions are /dev/sdXe. This is actually described in the NetBSD guide.

gaspachos78

nia

Hi, thank you for your reply.

there's very little point to having them

https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-934.pdf

GENERIC_KASLR

Yes,

$ uname -a
NetBSD localhost 9.2 NetBSD 9.2 (GENERIC_KASLR) #0: Wed May 12 13:15:55 UTC 2021 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC_KASLR amd64

I read this:
https://man.netbsd.org/secmodel_securelevel.9

Testing:

$ sysctl kern.securelevel
kern.securelevel = -1

I added the new line in /etc/rc.conf:

$ cat /etc/rc.conf | grep securelevel
securelevel=1

, and rebooted the system. Now, before the login prompt I see:

Setting securelevel: kern.securelevel: -1 -> 1

But still, I'm not able to find anything related to "efi=disable_early_pci_dma" in NetBSD's environment.

there's very little point to having ...

Here is:

From: Matthew Garrett matthewgarrett@google.com

Add an option to disable the busmaster bit in the control register on
all PCI bridges before calling ExitBootServices() and passing control
to the runtime kernel. System firmware may configure the IOMMU to prevent
malicious PCI devices from being able to attack the OS via DMA. However,
since firmware can't guarantee that the OS is IOMMU-aware, it will tear
down IOMMU configuration when ExitBootServices() is called. This leaves
a window between where a hostile device could still cause damage before
Linux configures the IOMMU again.

If CONFIG_EFI_DISABLE_PCI_DMA is enabled or "efi=disable_early_pci_dma"
is passed on the command line, the EFI stub will clear the busmaster bit
on all PCI bridges before ExitBootServices() is called. This will
prevent any malicious PCI devices from being able to perform DMA until
the kernel reenables busmastering after configuring the IOMMU.

This option may cause failures with some poorly behaved hardware and
should not be enabled without testing. The kernel commandline options
"efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma" may be
used to override the default. Note that PCI devices downstream from PCI
bridges are disconnected from their drivers first, using the UEFI
driver model API, so that DMA can be disabled safely at the bridge
level.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4444f8541dad16fefd9b8807ad1451e806ef1d94
https://mjg59.dreamwidth.org/54433.html

Every PCI device has a busmaster bit - if the busmaster bit is disabled, the device shouldn't start any DMA transactions. Clearing that seems like a straightforward approach. Unfortunately this bit is under the control of the device itself, so a malicious device can just ignore this and do DMA anyway. Fortunately, PCI bridges and PCIe root ports should only forward DMA transactions if their busmaster bit is set. If we clear that then any devices downstream of the bridge or port shouldn't be able to DMA, no matter how malicious they are. Linux will only re-enable the bit after it's done IOMMU setup, so we should then be in a much more secure state - we still need to trust that our motherboard chipset isn't malicious, but we don't need to trust individual third party PCI devices.

This patch just got merged, adding support for this. My original version did nothing other than clear the bits on bridge devices, but this did have the potential for breaking devices that were still carrying out DMA at the moment this code ran. Ard modified it to call the driver shutdown code for each device behind a bridge before disabling DMA on the bridge, which in theory makes this safe but does still depend on the firmware drivers behaving correctly. As a result it's not enabled by default - you can either turn it on in kernel config or pass the efi=disable_early_pci_dma kernel command line argument.

In combination with firmware that does the right thing, this should ensure that Linux systems can be protected against malicious PCI devices throughout the entire boot process.

So, "efi=disable_early_pci_dma" is very important option, it helps to resist against hardware
backdoors and malicious PCI devices. Is there any way to disable the busmaster bit in the
control register on all PCI bridges during very very very early boot in NetBSD's environment? Thanks.