lkml.org 
[lkml]   [2016]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions
On 08/14/16 at 12:25am, Brian Gerst wrote:
> On Fri, Jul 8, 2016 at 4:35 PM, tip-bot for Thomas Garnier
> <tipbot@zytor.com> wrote:
> > Commit-ID: 021182e52fe01c1f7b126f97fd6ba048dc4234fd
> > Gitweb: http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd
> > Author: Thomas Garnier <thgarnie@google.com>
> > AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700
> > Committer: Ingo Molnar <mingo@kernel.org>
> > CommitDate: Fri, 8 Jul 2016 17:35:15 +0200
> >
> > 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.
>
> This patch is causing my system to fail to boot. The last messages
> that are printed before it hangs are:
>
> [ 0.195652] smpboot: CPU0: AMD Phenom(tm) II X6 1055T Processor
> (family: 0x10, model: 0xa, stepping: 0x0)
> [ 0.195656] Performance Events: AMD PMU driver.
> [ 0.195659] ... version: 0
> [ 0.195660] ... bit width: 48
> [ 0.195660] ... generic registers: 4
> [ 0.195661] ... value mask: 0000ffffffffffff
> [ 0.195662] ... max period: 00007fffffffffff
> [ 0.195663] ... fixed-purpose events: 0
> [ 0.195664] ... event mask: 000000000000000f
> [ 0.196185] NMI watchdog: enabled on all CPUs, permanently consumes
> one hw-PMU counter.
> [ 0.196291] x86: Booting SMP configuration:
> [ 0.196292] .... node #0, CPUs: #1
>
> I'm taking a guess here, but it may be that this is interfering with
> the APIC accesses.

Seems it hang when startup 2nd cpu. It may give more information if
add below line to the beginning of arch/x86/kernel/smpboot.c and
rebuild bzImage.

#define DEBUG

>
> --
> Brian Gerst

\
 
 \ /
  Last update: 2016-09-17 09:56    [W:0.097 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site