Comment 19 for bug 1626269

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 <email address hidden>
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 <email address hidden>
    Signed-off-by: Kees Cook <email address hidden>

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://<email address hidden>/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