Hello, Here is an update on the situation.
I completed a kernel bisection between 4.7.8 and 4.8-rc1 (15 kernel builds) and identified the kernel commit that causes the problem : commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd Author: Thomas Garnier <thgar...@google.com> Date: Tue Jun 21 17:47:03 2016 -0700 x86/mm: Enable KASLR for physical mapping memory regions Add the physical mapping in the list of randomized memory regions. The physical memory mapping holds most allocations from boot and heap allocators. Knowing the base address and physical memory size, an attacker can deduce the PDE virtual address for the vDSO memory page. This attack was demonstrated at CanSecWest 2016, in the following presentation: "Getting Physical: Extreme Abuse of Intel Based Paged Systems": https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/blob/master/Presentation/CanSec2016_Presentation.pdf (See second part of the presentation). The exploits used against Linux worked successfully against 4.6+ but fail with KASLR memory enabled: https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/tree/master/Demos/Linux/exploits Similar research was done at Google leading to this patch proposal. Variants exists to overwrite /proc or /sys objects ACLs leading to elevation of privileges. These variants were tested against 4.6+. The page offset used by the compressed kernel retains the static value since it is not yet randomized during this boot stage. Signed-off-by: Thomas Garnier <thgar...@google.com> Signed-off-by: Kees Cook <keesc...@chromium.org> As you can see, this modification is specific to the x86 architecture which is why you don't see the issue. In parallel to that, a patch to fix this situation has been published yesterday to the makedumpfile mailing list and is currently under review by the main developper : https://www.mail-archive.com/kexec@lists.infradead.org/msg16628.html There is a debian bug opened for this issue : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842019 While I understand your concern, I cannot push a modification that will trigger makedumpfile to generate dozen of error messages and a potentially unusable vmcore to all of the x86 world in order to satisfy only one architecture. It is important to remember that, while makedumpfile fails, the kernel dump capture mechanism reverts to using 'cp' to copy /proc/vmcore uncompressed so this vmcore file is still usable for analysis. Hopefully, we should get an ACK for the upstream bug soon, so I can push a new package to Debian. I will then proceed with the synchronization to Zesty and SRU to the other stable releases. I hope that this clarifies the situation. Kind regards ** Bug watch added: Debian Bug tracker #842019 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842019 ** Changed in: makedumpfile (Ubuntu) Status: Confirmed => In Progress ** Changed in: makedumpfile (Ubuntu) Importance: High => Medium ** Changed in: makedumpfile (Ubuntu Yakkety) Importance: High => Medium ** Changed in: makedumpfile (Ubuntu Trusty) Status: New => Confirmed ** Changed in: makedumpfile (Ubuntu Xenial) Status: New => Confirmed ** Changed in: makedumpfile (Ubuntu Trusty) Importance: Undecided => Medium ** Changed in: makedumpfile (Ubuntu Xenial) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1626269 Title: Ubuntu 16.10: kdump is not working in 4.8 kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1626269/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs