Project

General

Profile

Feature #11886

Upgrade Linux to 4.8 and adjust our kernel tweaks accordingly

Added by intrigeri about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
10/25/2016
Due date:
% Done:

100%

Feature Branch:
feature/11886-linux-4.8
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

https://ftp-master.debian.org/new/linux_4.8.4-1~exp1.html reads:

       * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE.
         This breaks (e)glibc 2.13 and earlier, and can be reverted using the kernel
         parameter: vsyscall=emulate
       * Enable SLAB_FREELIST_RANDOM
       * security,printk: Enable SECURITY_DMESG_RESTRICT, preventing non-root users
         reading the kernel log by default (sysctl: kernel.dmesg_restrict)

Likely we can drop a couple tweaks we do, and should check if at least our slab_nomerge is still the best we can do.

noats.patch View (1.68 KB) cypherpunks, 11/11/2016 11:42 AM


Related issues

Related to Tails - Feature #11840: Increase mmap randomization to the maximum supported value Resolved 09/25/2016
Related to Tails - Feature #12090: Enable the slab allocator poisoning Resolved 12/27/2016
Related to Tails - Feature #12025: Default panic_on_warn to 1 Confirmed 12/09/2016
Related to Tails - Feature #12122: Upgrade Linux to 4.9 Resolved 12/27/2016

Associated revisions

Revision 8bb8d78c (diff)
Added by intrigeri about 3 years ago

Drop kernel.dmesg_restrict customization: it's enabled by default since 4.8.4-1~exp1 (refs: #11886).

(This branch still installs Linux 4.7, but I want to make it ready for 4.8.)

Revision a3039867 (diff)
Added by intrigeri about 3 years ago

Drop the vsyscall=none kernel option (refs: #11886).

It's the default on x86_64 since 4.8.4-1~exp1; according to
Documentation/kernel-parameters.txt the vsyscall= option only makes sense on
x86_64 anyway.

Revision 56417aea (diff)
Added by intrigeri almost 3 years ago

Revert "Drop the vsyscall=none kernel option (refs: #11886)."

This reverts commit a30398670d9daa3c6b01fd97594aa65848de432a.

4.18.15-1 will revert to LEGACY_VSYSCALL_EMULATE instead of
LEGACY_VSYSCALL_NONE (due to Debian#847154).

Revision 57081efd (diff)
Added by intrigeri almost 3 years ago

Upgrade the Linux kernel to 4.8.0-0.bpo.2 (refs: #11886).

Revision 75eaeea7
Added by anonym almost 3 years ago

Merge remote-tracking branch 'origin/feature/11886-linux-4.8' into devel

Fix-committed: #11886

History

#1 Updated by intrigeri about 3 years ago

  • Related to Feature #11840: Increase mmap randomization to the maximum supported value added

#2 Updated by cypherpunks about 3 years ago

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 #11827 also related, if #11840 is?

#3 Updated by cypherpunks about 3 years ago

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, 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).

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(tm), 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.

#4 Updated by intrigeri about 3 years ago

  • Target version changed from Tails_2.9.1 to Tails 2.10

#5 Updated by intrigeri about 3 years ago

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 about 3 years ago

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(tm), 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 :)

#7 Updated by intrigeri about 3 years ago

  • Status changed from Confirmed to In Progress
  • Feature Branch set to wip/feature/11886-linux-4.8

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

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?

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?

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.

Double-checked and then done on the topic branch!

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.

Worth considering! Please move this to a dedicated ticket though, since as you say it's not specific to 4.8.

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,

That's for another ticket, but before creating it to follow up on this, please consider the drawbacks. There's a reason why Intel IOMMU is disabled by default, see e.g.: https://lists.linuxfoundation.org/pipermail/iommu/2009-February/001053.html, https://lists.linux-foundation.org/pipermail/iommu/2009-January/001028.html, https://askubuntu.com/questions/816479/kernel-parameter-intel-iommu-on-causes-boot-to-fail.

#8 Updated by intrigeri almost 3 years ago

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.

#9 Updated by intrigeri almost 3 years ago

  • Related to Feature #12089: Enable the kernel page allocator poisoning added

#10 Updated by intrigeri almost 3 years ago

  • Related to Feature #12090: Enable the slab allocator poisoning added

#11 Updated by intrigeri almost 3 years ago

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 #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 #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 #12025.

#12 Updated by intrigeri almost 3 years ago

#13 Updated by intrigeri almost 3 years ago

  • Feature Branch changed from wip/feature/11886-linux-4.8 to feature/11886-linux-4.8

#14 Updated by intrigeri almost 3 years ago

  • % Done changed from 0 to 10

Pushed a branch with 4.8. The only change is dropping our custom kernel.dmesg_restrict=1 since it's now the default. Let's see what Jenkins thinks. Every other candidate change is now tracked in separate tickets.

#15 Updated by intrigeri almost 3 years ago

  • Subject changed from Adjust our Linux kernel tweaks to Debian's 4.8+ to Upgrade Linux to 4.8 and adjust our kernel tweaks accordingly

#16 Updated by intrigeri almost 3 years ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

#17 Updated by intrigeri almost 3 years ago

  • Related to deleted (Feature #12089: Enable the kernel page allocator poisoning)

#18 Updated by intrigeri almost 3 years ago

#19 Updated by anonym almost 3 years ago

  • Status changed from In Progress to 11
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

Merged, thanks!

#20 Updated by anonym almost 3 years ago

  • Status changed from 11 to Resolved

Also available in: Atom PDF