Tails

#2 Updated by cypherpunks 2016-11-11 06:52:15

The behavior of slab_nomerge hasn’t changed in 4.8, as far as I know. For improving boot parameters, it’s slub_debug which should be changed. Using the latter implies the former, but it’s good to use both for reasons outlined in the original ticket where the settings were added.

Page poisoning
If CONFIG_PAGE_POISONING=y and CONFIG_PAGE_POISONING_ZERO=y, then add page_poison=1 to the boot parameters. This will enable buddy allocator free poisoning. According to http://lxr.free-electrons.com/source/mm/slub.c?v=4.8#L740, the poison value is still 0x6b and 0x5a, which point into userland, so adding slub_debug=P might not be a good idea yet. The KSPP wiki page says that that flag is recommended though, and Kees wrote it, so that’s a bit conflicting. I’ll probably ask Kees on IRC and report back here. My guess is that it’s safe as long as page_poison=1.

Obsolete boot options
As for the tweaks we can drop, all I can think of is vsyscall=none and kernel.dmesg_restrict=1, if LEGACY_VSYSCALL_NONE=y, LEGACY_VSYSCALL_EMULATE=n, and SECURITY_DMESG_RESTRICT=y on this config.

Panic on warn
Another thing I think we should enable, though it’s not unique to 4.8, is the panic_on_warn boot parameter. This replaces WARN () with panic(), which is useful because many security features like CONFIG_DEBUG_CREDENTIALS and CONFIG_DEBUG_LIST trigger a WARN () upon violation. These are enabled by default in Debian’s kernel config, IIRC, but are not particularly useful for security unless the system panics when violations are detected. Unlike panic_on_oops=1, this probably won’t cause lots of issues for people with flaky hardware. Additionally, many miscellaneous cases which should never be hit in the kernel have WARN ()s, even when they can lead to degraded system security.

This could alternatively be implemented as a sysctl, kernel.panic_on_warn=1.

I/OMMU
I was going to create a dedicated ticket for this a few months ago, but I forgot and this ticket reminded me just now. I was surprised to learn that Debian’s kernel config does not enable the system’s IOMMU by default, so there is absolutely no isolation of devices attached to the system’s PCH. Adding intel_iommu=on (and maybe amd_iommu=force as well? I don’t have an AMD system so I can’t test this) will enable access to the IOMMU. The kernel will make use of this for DMAR, aka DMA remapping. This helps isolate devices from each other and from the system’s main memory. The ACPI tables (usually hardcoded in the BIOS) contain the DMAR mappings, which tell each device what ranges of memory it is allowed to access and where its memory accesses get redirected to. This will make DMA attacks harder. If a system lacks an IOMMU, these flags will do nothing.

BTW, isn’t Feature #11827 also related, if Feature #11840 is?

#5 Updated by intrigeri 2016-12-05 09:10:20

Not sure if it’s included in the above list, but since 4.6 one can opt-in for memory wiping (zero on free).

#6 Updated by intrigeri 2016-12-06 10:46:44

Hi!

Let’s not make this ticket track all possible kernel tweaks we might want to do. I want to use it to track only the adjustments we need to / should do when upgrading Linux to 4.8, so it can reasonably be completed in time for Tails 2.10. So:

> Some possibly experimental tweaks we could use are acpi_no_memhotplug, which disables memory hotplugging and could be useful for preventing physical attacks against some server-grade systems,

This was added in Linux 4.2 ⇒ off-topic on this ticket, please file a dedicated one about it if you think it’s worth it :)

> and pci=ecrc=on, which forces PCI/PCIe devices to use CRC codes for TLPs (PCI packets), which may make using certain logic analyzers and active injection devices on PCI/PCIe buses more difficult (than they already are).

This was added in Linux 2.6.31 ⇒ off-topic on this ticket, please file a dedicated one about it if you think it’s worth it :)

> I looked to see if there was a way to disable ATS (Address Translation Services) without recompiling the kernel (CONFIG_PCI_IOV, CONFIG_PCI_PRI, and CONFIG_PCI_PASID must all be disabled), but there was none. I wrote a simple kernel patch which disables ATS when pci=noats is passed as a boot parameter, though I haven’t tested it yet (it’s so simple that it’ll probably Just Werk™, but it’s not the first time I’ve said that and been wrong!). I might try getting it upstreamed into Linux if it would be acceptable to add to Tails when it hits Debian. I attached the file just in case anyone is curious.

Same, ATS stuff was added years ago ⇒ off-topic on this ticket, please file a dedicated one about it if you think it’s worth it :)

#8 Updated by intrigeri 2016-12-19 13:50:55

4.18.15-1 will include:

   * [amd64] Re-enable LEGACY_VSYSCALL_EMULATE instead of LEGACY_VSYSCALL_NONE.
     There are still binaries in stable that use vsyscall (via dietlibc).
     (Closes: #847154)

So I guess we should keep setting vsyscall=none ourselves.

#11 Updated by intrigeri 2016-12-27 09:44:18

intrigeri wrote:
> I think that’s the only remaining open question on this ticket:
>
> > If CONFIG_PAGE_POISONING=y and CONFIG_PAGE_POISONING_ZERO=y, then add page_poison=1 to the boot parameters. This will enable buddy allocator free poisoning.
>
> Sadly, CONFIG_PAGE_POISONING is not set in Debian’s 4.8.7-1 kernel. Shall we ask the package maintainers to enable it?

I’ve filed Feature #12089 to track this.

> > According to http://lxr.free-electrons.com/source/mm/slub.c?v=4.8#L740, the poison value is still 0x6b and 0x5a, which point into userland, so adding slub_debug=P might not be a good idea yet. The KSPP wiki page says that that flag is recommended though, and Kees wrote it, so that’s a bit conflicting. I’ll probably ask Kees on IRC and report back here. My guess is that it’s safe as long as page_poison=1.
>
> Any update from Kees?

This is now tracked on Feature #12090.

> > Another thing I think we should enable, though it’s not unique to 4.8, is the panic_on_warn boot parameter.
>
> Worth considering! Please move this to a dedicated ticket though, since as you say it’s not specific to 4.8.

Tracked on Feature #12025.