linux-kernel - Re: [tip:x86/boot] x86/mm: Enable KASLR for physical mapping memory regions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160814232657.GA10704@x1.redhat.com>
Date:	Mon, 15 Aug 2016 07:26:57 +0800
From:	Baoquan He <bhe@...hat.com>
To:	Brian Gerst <brgerst@...il.com>
Cc:	Borislav Petkov <bp@...en8.de>, Yinghai Lu <yinghai@...nel.org>,
	Juergen Gross <jgross@...e.com>, thgarnie@...gle.com,
	Andy Lutomirski <luto@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Alexander Kuleshov <kuleshovmail@...il.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>, borntraeger@...ibm.com,
	sds@...ho.nsa.gov, kirill.shutemov@...ux.intel.com,
	jroedel@...e.de, Kees Cook <keescook@...omium.org>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	Mark Salter <msalter@...hat.com>, Borislav Petkov <bp@...e.de>,
	corbet@....net, matt@...eblueprint.co.uk,
	guangrong.xiao@...ux.intel.com, aneesh.kumar@...ux.vnet.ibm.com,
	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>, toshi.kani@....com,
	alpopov@...ecurity.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jan Beulich <JBeulich@...e.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, dyoung@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>,
	Dmitry Vyukov <dvyukov@...gle.com>, lv.zheng@...el.com,
	schwidefsky@...ibm.com, linux-tip-commits@...r.kernel.org
Subject: Re: [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@...or.com> wrote:
> > Commit-ID:  021182e52fe01c1f7b126f97fd6ba048dc4234fd
> > Gitweb:     http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd
> > Author:     Thomas Garnier <thgarnie@...gle.com>
> > AuthorDate: Tue, 21 Jun 2016 17:47:03 -0700
> > Committer:  Ingo Molnar <mingo@...nel.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